This is about a design pattern for MVVM style development using WPF/Silverlight.
I feel that it is always cleaner and hassle-free to have ViewModel handle all the bindings data needs directly rather than using additional class objects to encapsulate data and then exposing that encapsulated data via public properties on view model.
Say, you have a view that display a name, list of cities and a boolean filed like IsRegisteredUser, then it is better that you have all those three fields exposed directly from ViewModel and let ViewModel store the state for them directly. If you try to use another class object e.g. Customer and then have those three fields as public property in Customer class, then you are unnecessarily adding an extra layer. You will then have to create public properties in ViewModel that internally hook into the properties of Customer class. So you end up having viewmodel managing the PropertyChangeNotifications and your Customer class maintaining the state. This style of binding gets very complicated as the number of properties increase in the Customer class and debugging gets equally difficult.
ViewModel is intented to flatten all the data needs of the view. So it can draw data from various sources but it’s best to allow ViewModel to directly flatten all complex data structures into flat set of public properties to be supplied to view and manage/maintain state directly.