MVVM as a pattern is about separating concerns, improving testability of your code, etc.. so your ViewModel should only be concerned with applying business rules and providing data for your View.
You will need to use this in conjunction with some kind of MVC pattern, where the Controller's concern is handling the application navigation/state, etc.
(edit)
For example, imagine your app has a login screen, so you create a LoginView, which contains a username and password; probably an OK button and a Cancel button.
You create a LoginViewModel class to bind this view and handle the logic of the login within this class.
But once the app is logged in, it is not the responsibility of the login ViewModel to know where to go next; or which View to render next.. maybe you want to navigate to the last screen this user was on the previous time they were logged in? Maybe it goes to a default screen, as per the User's profile? This decision is nothing to do with the login function...
So if you create a Controller class, you can: Instantiate an instance of the LoginViewModel class, then depending on the login result, apply business rules as required to remove the LoginViewModel from scope, and create a new ViewModel, (e.g. HomePageViewModel) etc...
Finally, you'll need to let the app know which Views to use for each VM using DataTemplates
There are heaps of other ways to skin this particular cat, of course... this is just one idea...
As long as the core concept remains: Use MVVM to bridge the gap between View and Model in a clean, testable way... don't try and make it the 'one pattern fits all' :)
HTH :)