This is certainly a controversial idea, and one that is frequently criticised, often in this manner. Although I don't *agree* with the criticism, I don't object to it ;). Its design rationale should be better documented, and for that I apologize.
Grin. There's no need to apologise - Twisted is a fantastic (free) system, and better documented than a whole lot of APIs I've had the (mis)fortune to use over the years.
However, although you may want a "user object" that is different than the page -- and in that case the top-level page should probably wrap that object -- the term "avatar" has a specific meaning. To be an avatar for HTTP, you must implement IResource.
You can disagree about whether this is the most generally useful design, but it *is* the specific design to which the jargon term "avatar" refers in the context of cred. Trying to re-define it so that it doesn't mean that makes an already confusing topic even more difficult to discuss. So please don't.
That was not my intention, and if you feel I've made a confusing statement then I'm sorry - let it be purged from the internets! By way of explanation regarding the basis of my thinking; the majority of the large web-app work I've done to this point is on Zope. It of course has the basic architecture of a tree of object instances. It would be unusual (to the best of my, admittedly not encyclopedic, knowledge) to spawn new instances of the entire page/object hierarchy when a user logs in. Instead the object-publisher walks the same tree, applying both zopes inbuilt permissions and making the user info available to pages/code on the request object. It's a model I like (along with a lot of other things about Zope, offset by some things I despise) and will have to give some thought as to whether to emulate or move away from.