Работа с данными в Angular

То что у Вас получилось из User сложно назвать моделью.
А для дополнения модели новыми полями лучше использовать мапер.
Например как на бэке мапятся entity(модель БД) и DTO, так же и на фронте можно сделать прослойку из маперов между приложением и слоем api сервисов.
Как вариант можно использовать библиотеку automapper-ts

А я для этих целкей использую библиотеку json2typescript. Описал класс модели, описал аннотациями декораторами поля json объекта, заинжектил сериалайзер в сервис и дернул там

map(result => this.serializer.deserialize(result, User))

и всё. И никакого бойлерплейта.

constructor(private User: UserFactory, private http: HttpClient) {
    http.get('/users').subscribe(res => console.log(res));
}

Фабрика писалась чтобы в конечном итоге все равно вызвать http?
Если нет, поправьте пожалуйста.

Как на счет варианта пойти angular путем и использовать Pipes.
Например, код конкатенации имени и фамилии вынести в следующий pipe.

@Pipe({ name: 'fullName' })
export class FullName implements PipeTransform {
  transform(value: any): string {
    return value.firstName, value.lastName].filter(el => !!el).join(' ');
  }
}

Таким образом решается проблема перегруженности шаблона логикой, повышается читаемость, плюс решается вопрос переиспользования,
ведь pipes можно вынести в SharedModule и использовать по всему приложению.
{{ user | fullName}}

---

Плюс бросился в глаза следующий фрагмент кода:

<img [src]="userService.getUserAvatar(user.id)">

Вызов функций в шаблонах пагубно сказывается на производительности angular-приложений.
Рекоменую, использовать также pipe + ChangeDetectionStrategy.onPush
Хорошее 5 минутное видео как раз по этому поводу с последней ngconf конференции:
www.youtube.com/watch?v=I6ZvpdRM1eQ

Компонент UserList изначально следовало разбить на компоненты UserList и UserListItem, а для поставленной задачи отображения полного имени замечательно подойдет соответствующий pipe, который очень легко переиспользовать, не создавая при этом «умные данные».

ссылка на аватарку пользователя не приходит сразу в ответе, а формируется на основе id пользователя

По хорошему, сервер должен отдавать готовую динамическую ссылку на любой статический контент подобного типа. В вашем случае придется заботиться о сбросе кеша, если она изменена и проверить есть ли она вообще; как реализовать приватность доступа к аватаркам; хранить пути к серверу и т.д. — и всё это не разрешимо на фронте. А нужно просто получить ссылку с сервера и всё ;-)

Можно вынести этот метод из компоненты в сервис.

Для этого существуют Пайпы.

мы переместили метод создания пользователя в UserService

Вместо решения проблемы, вы переложили её на плечи бедного сервиса. Ваша первая реализация класса User уже достаточна, далее не нужно было его замусоривать. Внедрив в него кучу сервисов, вы обрекли себя на муки поддержки в будущем (например, в другом месте приложения потребуется просто вывести имя, а у вас ещё вагон зависимостей).

Не бойтесь создавать модели и сервисы при первой необходимости. Вы сами того не замечая удивитесь, что сервис, о котором по началу не думали, уже используется в 10 местах. И рефакторинг в сторону упрощения и объединения всегда проще, чем расковыривать монстра с десятком зависимостей и сотней строк.

А на счет бойлерплейта уже выше вам написали.