Сергей

Читать про инициализатор MigrateDatabaseToLatestVersion, попробуй начать с этого.

Если в кратко:
AutomaticMigrationsEnabled = false;
Миграции должны быть именованными и сохранятся в проекте в виде файлов, что бы быть скомпилированными и присутствовать в сборке: "Add-Migration -Name v1".
при публикации устанавливаем флажок "Execute code first migrations (runs on application start)" или добавляем в раздел entityFramework->contexts описание нужного DbContext с описанием инициализатора (Пример с нужным нам MigrateDatabaseToLatestVersion в самом конце страницы).

Классы StaffReports_ и StaffReports1_ не нужны пишем просто:

в class Staff

public virtual ICollection<Report> StaffReports { get; set; }

в class Report

public virtual ICollection<Staff> Interns { get; set; }

Дальше конфигурируем (см. void OnModelCreating(DbModelBuilder modelBuilder)

Можно создать сущность привязать её к тем же таблицам и полям, что и identity, сгенерировать именованную миграцию и убрать в ней создание таблицы. Дальше можно добавлять свойства и связи на другие сущности.

ЗЫ
Работать с двумя моделями в одном проекте не очень удобно, можно вынести модель identity или новую в отдельный проект.

ЗЗЫ
А почему бы не добавить в существующую модель ?

Обычно при каждом запросе создается свой контекст. Потому, что во первых веб приложения обычно не хранят состояния (stateless), во вторых EF Context не предназначен для кэширования и с увеличением количества сущьностей в контексте начинает тормозить.

Окружать все try—catch я думаю смысла нет, лучше сделать хорошие кастомные странички ошибок.

Несколько контекстов в одной базе замечательно уживаются, нужно только для каждого указать свой ключ

internal sealed class Configuration : DbMigrationsConfiguration<Models.ApplicationDbContext>
    {
        public Configuration()
        {
            ...
            ContextKey = "ApplicationDbContextKeyName";
        }

перейти к именованным миграциям т.е. создавать их так:
add-migration -name "MigrationName"
что бы при желании "глазиком" посмотреть/исправить изменения. При этом будет необходимо каждый раз в командной строке указывать с каким контекстом работаем. Так что возможно лучше произвести объединение контекстов. Можно например перенести все сущьности в ApplicationDbContext сгенерировать миграцию, удалить из неё создание таблиц (что бы данные не потерять) и продолжать работать как привык.

WebAPI можно т.к. он уже на OWIN (нет зависимости от system.web), по остальным смотри зависимость от system.web если таковая есть то нельзя.

Насколько я понял вас интересуют простой способ создания Data Transfer Object (DTO), рекомендую посмотреть в сторону AutoMapper