I also have trouble following your original cutting up of the world,
but I have a couple of comments that might be relevant.

First, although Morphs and some of the discussion of them seem to be
oriented toward having a single object that is both a "model" and a
"GUI", one can certainly use Morphs in a more classical MVC way.  That
is, you build an interface out of Morphs, and hook them up with some
underlying, non-graphical model.  I've been doing this myself, and it
works fine.

Second, the work with Morphs and players is pointing toward a
different paradigm, involving tiles, scripting, and direct
manipulation.  I haven't played with that too much.

Third, there are two different approaches to keeping all the models
and views in sync.  Morphs have a quality called "liveness", in which
they periodically update themselves (see the #step method). The more
traditional way is for a dependent ("view") to register itself with a
"model" and ask the model to inform it when things change.  There are
2 generations of that approach.  The classical smalltalk one uses
update/changed messages.  The newer one uses events, and messages like
#when:send:... and #trigger.  

The event framework is more aesthetically pleasing to me because it
allows you to send arbitrary messages (rather than just #update) when
something happens.  The classical update/change processing usually
begins with the receiver doing a switch on the "aspect" argument that
has changed to discover what is going on, which is a little ugly.

I have found there is a noticable overhead with the stepping if you
have lots of objects (even if they don't step--just going through the
list of candidates takes time).