Yes, separating out the part of the code that displays the menu (or does some other particular thing) into a function is a good idea, and can help with code organization (and code re-use). Your first function is good (but neither way is wrong).
For your second example... in C++ the use of exit() is not recommended, because it abruptly kills the program without doing any cleanup. C++ has a powerful feature called the destructor, which won't be properly run after a call to exit. The program's flow should be changed to end in main() and return from main instead. exit() (or terminate) should be reserved for scenarios like, "crap, something is totally wrong and I have no idea how I got into this situation or how to recover from it. Better to just kill the program at this point." [also consider throwing an exception instead of calling exit].
But that particular issue aside, I don't see a problem with it. If you are going to be calling a function multiple times, and want to give it a shorter name because it's used more often, then sure that's very appropriate.
I will even go so far as to say that exit()/terminate() and so on should be reserved for specialty uses only. For example if you have hardware that your software can damage, a full stop may be the way to go. But for typical programs, I would say the following is usually true... if you can detect a problem and call exit() then you can also detect the problem and unwind back to main to call return(0) after logging/alerting/etc the problem. Getting back to main and exiting (zero or not) is preferred, in that case. Exit failure code is about worthless. If you are going to use the return codes, define them so the user can tell what went wrong, eg define 1 means not enough command line args, 2 means could not open some file, whatever... and return the one that makes sense (or if you want to get really fancy, use powers of 2 and 'or' multiple problems together).