Using a property is definitely the way to go, especially from an MVVM standpoint. Think Occam's Razor: basically, the simplest solution is usually the best.
It's certainly the cleanest solution, and thus most maintainable. Plus, it is the most expandable (you can easily add new properties for different calculations if you'd like).
All you need to do is create read-only properties, and call PropertyChanged with that property's name when the collection changes (which it sounds like you are doing).
For example, here's an "Average" property:
public Double Average
{
get { return mMyCollection.Average(); }
}
void mMyCollection_CollectionChanged(object sender, NotifyCollectionChangedEventArgs e)
{
PropertyChanged(this, new PropertyChangedEventArgs("Average"));
}
Attached properties won't work - they are for specifying a parent's property in a child element.
ValueConverters would work, in theory (although they would probably have to be on each item in the list, as well as the entire collection), but you're not really converting anything, you are providing additional data based on existing data. To do that, you would need to muck around with all kinds of Templates, and any time you needed to change anything, you'll need to muck around with them again. It would get complex in a hurry, and for no benefit.