I do not. I plan on writing a blog post on this topic within the month that'll have examples. I'll ping you on twitter when I post it.
In the meantime, the Sproutcore todos app has a simple example of this:
https://github.com/sproutcore/todos/blob/master/js/app.js#L2...
The allAreDone propery. It's not something you'd have in the canonical data you'd send to/from the server but exists as a property so it can be observed and so the template bindings can manipulate it.
> If you now have both "model" and a "view-model" for the same resource, one of which has been adopted to be more checkbox-y, just so that its attributes correspond more closely with the DOM ... it would be a shame.
The model is more checkboxy but the checkboxy bits are initialized from the canonical bits and your sync equivalent has to strip them back off. This is annoying but less annoying than DOM twiddling.
(It seems there's an overwhelming consensus forming around issues like this - which FaxJs addresses at the core.)
I think that I'd tend to agree with your interpretation -- you write:
That sort of approach would be against the Backbone "party line". A large part of the point is to have your canonical state for a given resource in one place: the model. If you now have both "model" and a "view-model" for the same resource, one of which has been adopted to be more checkbox-y, just so that its attributes correspond more closely with the DOM ... it would be a shame.