Не совсем. В идеале для меня так:
Вьюшка - отображает. Очень удобно тем, что невозможно отображением подпортить логику игры. Добавил вспышку света при взрыве гранаты - и никак не может произойти так, что из за вспышки у врага на крыше упали штаны. Такие баги допустить очень легко, когда всё в куче. Ещё удобно тем, что разработку можно вести на уровне кружочки-квадратики и не ощущать скованность из за неполноты представления - добавляя отображение мы меняем 33% кода, вместо всей 100 (если представить что модель-контроллер-вьюшка имеют равный объем кода, что почти всегда неверно
). Очень удобно когда ещё люди не знают, как будет выглядеть игра. Есть логика игры, а вот над представлением ещё думают, есть мелкий концепт. Чертовски удобно когда несколько видов игры - например вид сверху и вид сзади (3д, но игра функционала такого же как в 2д).
Модель - ну тут в идеале - полная информация о процессе. Идеальная модель для меня - это если удалить вьюшка и контроллер, а потом создать их снова чистенькие и отдать эту модель - всё восстановится в точности/почти в точности, как было раньше. Очень удобно для сериализации: если она не DisplayObject - то просто записываем в ByteArray - получаем AMF объект, который можем сохранить... да хоть в файл. Некоторые в качестве модели используют DisplayObject`ы, ради иерархии и бабблинга событий. Врать не буду - в целом идея удобная, а сериализовывать модели... ну лично мне не приходилось никогда. С другой стороны DisplayObject`ы едят больше памяти, чем просто EventDispatcher`ы, так что эти моменты весьма спорные. Но это я от темы отхожу.
Контроллер - ерунда которая всем этим делом управляет и содержит все мозги.
Такое разделение помимо описанного может сыграть в плюс при работе в команде - менее опытный программист пишет вьюшку, более опытный - логику, и делается это почти паралельно. Такой практикой не занимался, но я думаю она вполне имеет место быть.