MVVM confusion

I've looked at many of the lbugnion's samples and videos and i am quite confused with the MVVM concept. Here are my following confusions

1.) If we are dealing about separation of concerns, shouldn't the model class be as poco as possible? This will allow easy portability between multiple projects even if they don't make use of the MVVM design pattern( since it's isn't really viable in other
types of projects)

examples:
Should model really implement inotifypropertychanged or should the view model wrap it?

2.) Are the viewmodels meant to be portable across MVVM applications like the models? Should i strive to create viewmodels with portability so i can use them in other applications using MVVM?

3.) I see many examples online implement IDataErrorInfo within the model class and some implement it within the view model. Is there a preferred way?

If you implement it within the view model, then you keep your models poco.
On the other hand,
if you implement it in the model, then business logic follows the class around into projects wanting to use the models!

Summary: all in all my confusion is on whether i should do the following
1.) Should i Strive to make models poco as possible
2.) Should i strive to make view models as portable as possible

To 1:
In the beginning I was wrapping all my model objects in VMs. However in time, I noticed how much work that is. After talking to a few people in the industry, I changed my mind and rather (where possible) implement INPC on the Model object. Consider this:

INPC does not change the model object in a big way. The model object is still serializable.

Some other frameworks that create data objects automatically already have them implement INPC (think of Entity Framework or WCF). The proxy that these frameworks create have INPC already implemented.
Because of these considerations, and because it is really much easier than wrapping every single model object, I think that implementing INPC on the model object is acceptable.

To 2:
Yes and no. If you have the same app running on Windows 8 and Windows Phone, for instance, then sharing the VMs is probably a good idea. If however you have two completely different apps that use the same Model, the chances are big that the ViewModels will
be quite different between the two apps. So in that case it might not make sense to share the VMs. It’s really a case-by-case call that I make.

To 3:
I think that if you can, it is better to implement it on the Model, as validation is something that should be done quite low in the layers. But I can imagine some cases where it makes more sense on the VM layer.

To 1:
In the beginning I was wrapping all my model objects in VMs. However in time, I noticed how much work that is. After talking to a few people in the industry, I changed my mind and rather (where possible) implement INPC on the Model object. Consider this:

INPC does not change the model object in a big way. The model object is still serializable.

Some other frameworks that create data objects automatically already have them implement INPC (think of Entity Framework or WCF). The proxy that these frameworks create have INPC already implemented.
Because of these considerations, and because it is really much easier than wrapping every single model object, I think that implementing INPC on the model object is acceptable.

Along this same line, for Entity Framework Code First, should I be deriving all of my POCO classes used in EF from ObservableObject?

From what the original developer told me is that while the Local property of the DbSet collection might already implement INPC, it appears that it doesn't register a property changed event on the entire collection if one of the objects in the collection is
modified, which we need to know in the app. So he believes that each POCO needs to derive from ObservalbeObject. Do you agree?