Yes, basically the idea is that your viewModel should only be used by one view. If you use a viewModel to populate an area (like in ASP.NET MVC) then that viewModel is "reused" each time that view is presented in difference places.
This article is a discussion by Josh Smith of the MVVM pattern. Then, Ward Bell discusses in this article what he thinks Josh left out, while maintaining that Josh's work is still very strong.
Ward does an excellent job of laying out the complexities of this pattern and showing the tension that exists. Here is his take on the tension:
In my experience there is a “dialog” between View and ViewModel design. The VM exists to serve a view even as it strives for independence from any particular concrete view. A VM is useless if there is no view that will work with it; clearly the VM developer must
heed the imprecations of the View developer.
On the other hand, in business applications the application’s imperatives – what the view must do to satisfy business requirements – are the province of the programmer and are > best articulated through the capabilities of the ViewModel.
Therein lies the necessary tension between View and ViewModel design. As a developer my allegiance is with the ViewModel (“the application should do something worthwhile”) but it would be silly to defend that allegiance at the expense of the View (“a good UX is essential to making an application easy to learn and to use”).