I'll try to answer your question at the best of my capabilities... I hope I understand your scenario properly.
You have a large set of homogenous data (or at least a set of clusters of homogenous data), and you want to display them in different views; every view can select a sub-part of the complete set and eventually a subset of the properties.
If I did not misread your post, you already have a cache for the homogenous data your are going to display (PeopleInfoBO), and another one for specific view-models (PeopleInfoViewModel).
As far as I can see you have already dealt with the major issue of your application (i.e. caching data from the DB to avoid to retrieve the same information multiple times), and you already have decided that
PeopleInfoViewModels should be cached too (which is a good idea, since you need to share them among views).
Now, regarding how to handle the lists of such view-models, I would answer with a citation from Donald Knuth:
We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil
What I mean is that it is often inefficient to try to optimize something without having a clear understanding of the situation.
Let's say that you use a simple approach, and you create a new PeopleInfoListViewModel every time a new view is displayed. At creation time, you pupulate the Items collection of the view-model by pulling all the proper view-models from the cache. Depending
on how the application performs while generating the view for a list, you could decide to keep this implementation or execute your insertions using multiple batch insertions (e.g. on view-model intialization start a DispatcherTimer that pulls a small amount
of the required data from the cache and inserts them in the Items collection). Then, you could notice that, since list view-models are hierarchical, you could just re-use them in the upper levels of your hierarchy (e.g. the StateList view-model could contain
multiple CityList view-models, instead of a list of PeopleInfoViewModels, and the view could be responsible to 'merge' them).
All in all, I think it is too difficult to design something to be 'optimal' before-hand. I would go with a simple (yet meaningful) approach, test the application to point out the eventaul flaws, and take decisions depending on the test results (what if the
caching is too intense and the application keeps requiring too much memory?).
Regarding the refreshing of already existing view-models, it really depends on how you keep the view-models synchronized with the BOs, and if they are unique for each BO (shared among different list view-models). Assuming that you are sharing
PeopleInfoViewModels, you could decide to refresh them upon each activation, or (depending on the cost) use an asynchronous timer to refresh them periodically... again, I think that you need to first decide for a simple and effective approach, and
then refine it if needed.
I hope this post is meaningful to you...