Разделить приложение по паттерну MVC,
Ваш MVC плавно превращается в MVA, а MVA плавно превращается в луковую архитектуру.
и слоя такого как модель нет
Потому что модель это не слой, это объект. Один одинешенек (в контексте одного реквеста) такой... его задача взять запрос и выплюнуть данные. То есть для контроллера модель это сервис, для шаблона модель это... сущности или DTO.
Модель это ВСЕ ЧТО УГОДНО что умеет обрабатывать данные и содержит их.
Symfony же это UI фреймворк, который всего-лишь позволяет вам быстро организовать UI к вашему приложению (HTTP API или CLI скрипты это только UI приложения) и потому как именно вы будете организовывать архитектуру приложения - это чисто ваша забота. Симфони вам предоставляет только контейнер зависимостей что бы организовать сервисный слой удобненько.
MVC это бесполезные три буквы которые не говорят ровным счетом ничего о том как у вас чего организуется. MVA уже лучше и это именно то что использует подавляющее большиинство на бэкэнде последние лет 10 (в том числе и RoR), но концепция та же - разделение логики представления данных от логики обработки этих данных.
Тогда как поступить с этим? Есть компонент форм для валидации данных и заполнения полей авторизации-регистрации, есть ORM а как мне связать и валидацию и записи через ORM в объект User допустим.
Вам как правильно сделать или как удобно? Как удобно зависит от вас. Вы можете и писать из форм прямо в сущности анемичные и т.д. и еще как хотите. Но по сути флоу должен быть примерно таким:
компонент форм пишет данные в DTO (тупые контейнеры данных). DTO идут в сервисный слой где данные мэпятся на сущность. Сущности (у нас же это пропел)... по правилоному за их сохранноть должны отвечать репозитории, а внутри уже что угодно используйте, но раз уж у нас active record то все что мы можем тут сделать - просто вызвать save в сервисах либо страдать (доктрина в этом плане намного удобнее но у нее есть свои проблемы, а так же она сложная).
Но я крайне сомневаюсь что вы откажитесь от удобств и станите делать DTO. Скорее всего для вас просто не будет в них профита, они нужны для инкапсуляции сервисного слоя, то есть что бы UI ничегошеньки не знал о том как реализовано нутро, что бы вы могли все менять когда захотите. Сущности - это деталь реализации сервисного слоя, они никогда не должны попадать в контроллеры, но иногда это удобно. А хорошая архитектура - это та с которой удобно работать в конце концов (то есть мы балансируем между простотой и изоляцией изменений).
Так же рекомендую почитать вот эту штуку:
The Twelve Factors
