I was actually once involved in working on a web app, which we eventually almost ended up marketing as a standard "desktop application". For some reason, Marketing got it into their heads that one of our major clients wanted the product to "appear to be a GUI application", so we created a little Windows app that just hosts the IE ActiveX control, and points to our web app (hiding the fact that it's actually a browser). So effectively, to an untrained eye it looked like the product was a standard GUI app.
Granted, this isn't exactly what you're asking (we were still pointing at a web app, and not hosting the whole thing locally) - but it's close enough. It would have been trivial - minus some of the remote web services it used - to set this up to just have the whole thing sitting on the local machine.
Here was the biggest problem though: look and feel. Especially feel.
People expect certain behaviours from rich GUI apps (drag and drop, native-feeling windows and dialogs, etc). It is extremely hard to get a genuinely native look and feel from a web frontend. There is simply a different user flow in what is expected when you open up a web app in a browser (eg. Gmail), as opposed to when you use a rich GUI application (eg. Outlook). In my experience, trying to equate the two is asking for trouble. If you put out a "GUI app" which acts like a web app, you're likely to be flooded with usability and LAF complaints.
TL;DR - Web apps and GUI apps have different looks and feels, and a different user culture to some extent. While it's technically possible to do something like this, from my experience, I wouldn't go there (again). At best you're likely to end up with a horrendous mix of client-side scripting that will be more difficult to learn, use and maintain than doing the whole thing as a normal GUI app in the first place. And people WILL complain about things "not quite feeling right" for a native GUI app. It's tempting to think that they won't - but they will.
cout always writes to the standard output stream (stdout). If you want the output to be redirected elsewhere (e.g. a graphical window) you will have to pipe the output to another program or thread responsible for handling the graphical interface. There are many ways this can be done but it depends on the operating system somewhat.
By default, on Linux you can observe the stdout of both console and graphical programs just by running it from a terminal. In fact, there's really no clear-cut distinction between "console" and "graphical" programs in Linux.
On Windows it's rather different: console and graphical programs are distinct*. Graphical programs do not have a terminal allocated by default, so stdout messages usually end up in oblivion. There is a little bit of trickery required to allocate a terminal for graphical programs (so that they behave similar to Linux).
(I can't comment on Macs as I don't use them.)
You can do redirections externally via the shell. Here I assume a Bourne-like shell.** Say you want to run a program my-simulation and feed its output to another program my-display, which presumably reads from the standard input (stdin). If you run the program as is, the output will be dumped into the terminal as usual:
./my-simulation
You can establish a pipe by running the following in the shell:
./my-simulation | ./my-display
Or if you want to write to a file instead,
./my-simulation >my-output-file.txt
Of course, these can all be done in C/C++, but with more work. If you want stdout to be redirected to a file, you can use freopen from the standard library. Redirecting stdout to another process is slightly more difficult as you need to use platform-specific API to deal with processes and piping file descriptors.
[*] In Windows lingo, graphical programs are called Windows applications. You can find more about the various differences between these two kinds of programs on the MSDN.
[**] You can also do something similar with Command Prompt on Windows, but with a slightly different syntax.
Best Answer
Some of the reasons you might want a GUI are:
I suspect that the main thing that would motivate you, based on your description, is the first one. If you have some users that aren't comfortable with the command line interface, then you may want to provide a GUI.
One thing to consider, there are a few applications I have used that basically build their GUI as a front end for the command line version, so there is a lot of shared code.