Другими словами: нужен ли еще один класс, реализующий IUser, используемый как DTO в работе самого WebAPI?
В Вашей ситуации слой сервисов должен возвращать в WebApi DTO, но реализовывать его как IUser не стоит. Разделение системы на слои подразумевает что каждый слой может знать только о нижележащем слое (точнее о его интерфейсах). Если DTO, возвращаемое в WebAPI, будет реализовывать IUser относящийся к DAL произойдет нарушение порядка слоев, что как бы ни разу не тру.
Получается 3 почти идентичных куска кода: IUser, User (DB), UserViewModel (WebApi).
Вы этого никак не избежите, если хотите делить приложение на слои... сейчас у Вас структуры данных - идентичны, но со временем в системе может что-то поменять и они таковыми перестануть быть
Есть немного другой путь: не использовать EntityFramework (вполне реальные кейсы), взять, например, Dapper. Там в классе User не будет атрибутов, он будет чистым DTO. И теоретически, мог бы использоваться в WebAPI, но тогда придется сделать прямую ссылку на Project.Data.Impl.
Если User останеться в DAL - тогда проблема не решиться, у Вас по прежнему будет нарушение порядка слоев ...