We use a similar pattern that we internally call "Actions". An Action, in our parlance, is similar to the Command pattern from the Gang of Four. It can be invoked from anywhere and performs a single state change on a single model, or even multiple models (if several need to be updated at the same time, in the same transaction).
Separating Actions from Models was a huge step in writing readable code, and it's immediately clear what is happening in the system at any given time. Any Action can invoke any number of "child" actions, as well, to maintain encapsulation. For example: when a user registers on the site, we trigger a RegisterUser action, which in turn calls a CreateUser action and a LoginUser action.
Basically, we took any complicated method on our models and turned them into Action classes. Common concepts like database transactions, logging, event tracking, and so forth, can now be abstracted away, and don't need to be re-implemented in each model class. It's a huge productivity increase and a real win for software engineering.
I highly recommend this general approach to any large software system, and I'm grateful that we're all experimenting with things beyond MVC.