JS (Jquery): разделение логики и представления

Сам озадачен этим вопросом. Сейчас копаю в сторону Backbone js .

На клиенте также можно применить движок шаблонов, например Mustache.js. Так можно отделить представление. Данные будут по прежнему приходить в JSON. Кстати паттерн MVC очень неконкретный, в частности, его можно применять где угодно, не только исключительно в веб, на сервере.

Здравствуйте. Проблема со смешиванием view и model не решается каким-либо фреймворком - все зависит исключительно от людей, пишущих код, если в вашей компании принято не разделять контроллер и логику, один человек едва ли заставит всех сразу изменить подход.
Создавайте модель в виде объекта и некоего контроллера к нему. Создаем объект с полями, от которых зависит форма, реализуем зависимости (например через getters или явное указывание зависимостей (второй вариант мне кажется более оптимизированным - поможет сэкономить количество итераций одного и того же кода)), биндим зависимости на view.
Этот подход используется в knockoutjs
Плюсы этого подхода в элегантности кода - он прозрачен, контроллер пишется один раз, а далее вы оперируете только объектом модели и биндами с view. Минусы в реализации модульности - для реализации модульности, придется дорабатывать контроллер. И еще ладно если вам нет нужды прятать объект модели - глобальным просто оперировать, в противном случае придется прятать в замыканиях или геттерах/сеттерах.
В вашем случае - это не оптимальный вариант - так как необходимо будет придумывать функционал по обновлению модели.

Использование модульного подхода - как я говорил, использование какого-то определенного фреймворка не избавит вас от этой проблемы. Можно отлично управляться и с jquery+native кодом.
При реализации определенных функциональных требований планируем архитектуру как набор независимых модулей.
Явно выносим в отдельные функции операции по (например) вычислению суммы товаров, работы с КЛАДРом или персональной информацией, а потом оперируем ими как набором шаблонов. Создаем страницу, подключаем уже готовый конструктор, дергаем определенные модули с определенными настройками, получаем полностью готовую страницу.
Это путь к написанию собственного фреймворка.
Мне кажется в вашем случае - это хороший вариант - особенно если вы можете использовать какие-либо реализации jsonp. Это подходит и если вы используете парсер json объекта в html или же вы получаете чистый html обернутый в json. Получаем набор элементов и модуль к которому они относятся, получаем инструкции от модуля, отдаем html код в обработчик, навешиваем на него необходимые методы и запускаем модуль.

Никто не мешает объединять эти два варианта, но конечно, архитектуру своего фреймворка придется подогнать под первую архитектуру, это может быть проблемно из-за реализации биндов в первом варианте - обычно реализуют через событийную модель, тогда, если ваш фреймворк будет взаимодействовать непосредственно с view, необходимо каким то образом "заводить" первую архитектуру - либо дергать событийную модель, либо писать функцию обновления зависимостей.
Это лучший вариант в вашем случае - в любой момент можно узнать какие модули функционируют, оперировать модулями как единой группой, включать/отключать/приостанавливать и вообще делать с ними все что хотите, для этого необходимо будет
1. Создать связку model unit - view unit
2. Создать набор методов, необходимый для нормального функционирования view unit (возможно вы используете одни и те же методы для нескольких участков кода, типа XXXmaskDisable) (это этап, когда заканчивает отрабатывать парсер json объектов)
3. Создать объект оперирования связкой model unit - view unit (первая архитектура)
Плюсы, которые вы получите от этого:
1. Чистый код (очень простой, очень явный, настройкой объектов могут заниматься и джуниоры, не обязательно понимать как работает весь код)
2. Pattern подход и модульная структура - написание своего модульного фреймворка позволит повысить производительность frontend разработчиков, так как им не понадобится описывать всю модель при создании каждой новой страницы.
Попробуйте, это выгодно.