Алексей Гагарин

Я не понял, а модель-то кто будет передавать во View, дядя Вася что ли?
Вы вызываете свой индекс без модели. Это первое.
Второе, как уже сказали: при каждом новом запросе к серверу создаётся новый экземпляр контроллера. Т.е. при создании пользователя создаётся первый контроллер и пользователь добавляется в его лист.
При вызове Index создаётся другой контроллер, список которого пуст. Поэтому реализуйте хранилище для тестирования, например статичный класс MemoryUserRepository и засуньте свой лист туда.

Я думаю, что ответ даже проще, чем кажется. Просто с выходом платформы .net Microsoft хотела привлечь на свою сторону программистов, пользующихся Visual Basic.
Разумеется всегда можно переучиться и начать программировать на C#, но не всем это удобно, поэтому откажись MS от VB, она просто потеряла бы немалую часть пользователей, потому что им просто нравится VB и они хотят программировать именно на нём.
Поймите, что если вы не знаете программистов на VB или вакансий нет на биржах, то это не значит, что им никто не пользуется.
И дело тут отнюдь не в простоте или каких-либо преимуществах, хотя, например, код LinqToXml на VB выглядит элегантнее.
Ну и плюс, как правильно сказали, поддержка проектов, которые изначально написаны на VB.

Вообще странно, честно говоря, слышать такие вопросы в сообществе людей, где до сих пор верстают под Internet Explorer 6. Т.е. о жалкой доле процента пользователей вы беспокоитесь, а над огромной армией программистов VB удивляетесь? )))

Я использую SimpleMembership потому что для меня он прост, я его более или менее знаю, плюсом к тому он достаточно лёгок и гибок. Но с выходом MVC5 рекоммендуют использовать, как посоветовал комментатор выше, ASP.NET Identity. С ним я не работал.
Старый Asp.Net Membership использовать однозначно не рекоммендую, потому что в своём объёме и оптимизации он просто монструозный.

p.s. Вот вам очень полезная ссылка на тему авторизации. Мне в своё время очень помогла да и сейчас помогае

kevin-junghans.blogspot.ru

Paulskit правильно сказал, что автор пытается написать паттерн Repository. А Lam правильно написал как сделать GenericRepository.
Пример обобщённого репозитория, кстати, есть здесь www.asp.net/mvc/tutorials/getting-started-with-ef-...
Я в своём первом проекте его использовал. На самом деле, лично в моём понимании, это не очень хорошо.
Сейчас ваш метод возвращает объект по его ID. Предвижу, что следующим методом будет получение группы объектов и возвращение IQueryable. Такой подход невольно заставляет писать код выборки объектов где-нибудь (в контроллере, в слое сервиса), но не в репозитории, что приводит к путанице. На мой взляд, лучше делать не обобщённый репозиторий, а уникальный репозиторий для каждой сущности, необходимой для работы программы.
Предположим, что у вас есть класс BlogPost. Вы хотите иметь возможность загружать этот объект по ID, загружать вообще все эти объекты в память, загружать только часть этих объектов в память, загружать объекты с определённым условием и т.д. Для этого мы можете создать BlogPostRepository и написать в нём эти методы. Тогда ваша программа станет логичнее и понятнее. При работе с блогами вам не нужно будет каждый объявлять обобщённый репозиторий и городить поверх него запросы типа

var repository = new GenericRepository<BlogPost>();
var blogs = repository.GetAll().Skip(100).Take(10).OrderByDescending(c => c.Created);

Ну или как-то так (код примерный). Причём такие конструкции придётся городить в любом месте, где понадобится получить 10 последних блогов.
Проще сделать не обобщённый репозиторий, а специальный репозиторий для нужного объекта, тогда получится примерно так:

var repository = new BlogPostRepository();
var blogs = repository.GetTenTopBlogs();

В методе GetTenTopBlogs, соответственно, инкапсулируете логику выборки последних 10 блогов. Разумеется GetTenTopBlogs может иметь параметры (например количество блогов, которые нужно получить). Тут уже всё зависит от задач. И GetTopBlogs Должен возвращать IEnumerable, чтобы вызывающий код уже оперировал с сущностями в памяти, а не строил новые запросы к БД.
В целом код становится лаконичнее. Вам не нужно теперь каждый раз, чтобы что-то получить, объявлять обощённый репозиторий, тащить из него Queryable коллекцию и делать на ней выборку. Вы только вызываете метод и уже получаете результат. Теперь в вызывающих классах нет логики выборки.
Примерно так... :)
У Александра Бындю есть хорошие статьи на эту тему.
blog.byndyu.ru/2011/08/repository.html

Кстати, только заметил. Насколько я могу судить, репозиторий не должен знать об объекте DbContext. Это нужно для того, чтобы реализовать паттерн Unit Of Work. Представьте, что вы хотите совершить несколько транзакий (операций с репозиторием). Причём если хотя бы одна из них прошла неудачно, нужно всё откатить обратно. Предположим, что вы хотите сохранить 3 разных сущности в базу. Для этого вы написали свой обобщённый GenericRepository и объявили три переменных для каждой сущности. Причём у вас в этом GenericRepository будет функция Save (иначе как вы будете сохранять свои сущности).
Выходит, что каждый экземпляр класса GenericRepository будет содержать свою копию DbContext, и каждый раз после добавления сущности вы будете сохранять базу.
Единой транзакции не получится.
Чтобы получилась, нужно передавать DbContext в конструктор репозитория и ничего не сохранять в репозиториях. Т.е. вы где-то объявляете свой контекст, затем создаёте три репозитория и в каждый из них передаёте этот контекст. Делаете все операции, после чего сохраняете контекст в вызыывающем класе. Получается UoW. Хотя DbContext - это уже UnitOfWork.
По ссылке выше это тоже обсуждается (смотрите там рекоммендованные ссылки).

p.s. Paulskit дал хорошую ссылку, я как раз её пытался найти.
Lam тоже говорит правильно о том, что общие методы можно, конечно, вынести в обобщённый репозиторий. Только зачастую там этих методов - 1-2, а доброй трети сущностей эти методы вообще не понадобятся, так что я бы не стал делать лишнюю иерархию только для того, чтобы всем репозиториям назначить базовый класс.