Вот неплохо описана ответственность ViewModel:

Модель определена так же, как и в MVC; это данные или бизнес-логика, полностью независимые от UI, которые хранят и изменяют свое внутреннее состояние (хз, как прально перевести "does the processing of the problem domain"). Модель полностью описана кодом или представлена чистыми данными в виде взаимосвязаных таблиц или XML-данных.

Вид в концепции MVVM состоит из визуальных элементов, кнопок там, окошек всяких, графических элементов и более сложных элементов GUI. Он обрабатывает нажатия клавиш, да и вообще занимается взаимодействием с внешними устройствами ввода данных, что является областью ответственности контроллера в MVC (то, что действительно произошло с контроллером в современной разработке GUI - это отдельный и непростой вопрос... я предпочитаю думать, что он отступил на задний план. Контроллер в том виде, что описан в концепции MVC по-прежнему существует, однако играет уже совсем не такую значимую роль, как то было в 1979 году). Вид сейчас почти всегда объявляется декларативно, очень часто при помощи какой-то специализированной утилиты. Из-за особенностей таких утилит и вообще декларативного стиля некоторые состояния вида, которые MVC легко хранит в присущих ей классах видов, непросто реализовать. Например, UI может иметь множественные состояния, такие как "режим просмотра" и "режим редактирования", которые влияют на поведение визуальных элементов или на сам их вид, однако эти состояния не всегда можно выразить только лишь в виде XAML разметки (хотя и существует такая клевая штука, как триггеры).

Вот тут и вступает в игру привязка данных. В простых примерах вид привязывается непосредственно к модели. Часть ее просто отображается в виде путем однонаправленной привязки данных. Другие части модели могут быть отредактированы путем двунаправленной привязки контролов вида к данным модели. Например, свойства типа Boolean в модели могут быть привязаны к CheckBox'ам, или строковые поля - к TextBox'ам.