Собственно, свой механизм делать не стоит, бред. Это делается, чтобы среда ASP.NET (в частности ASP.NET MVC не ругалась на его отсутствие). Лучше создать модуль-заглушку, который ничего делать не будет. И в общем и целом производительности ради. Сессии нам не нужны.
Итак, берем наш файл web.config и удаляем оригинальный модуль поддержки сессий:
<httpModules>
<remove name="Session" />
</httpModules>
Откуда мы узнали под каким именем зарегистрирован оригинальный модуль? В файле web.config, который лежит в папке /windows/Microsoft.NET/Framework/версия-фреймворка/config/.
Затем, регистрируем свой фиктивный модуль:
<httpModules>
<remove name="Session" />
<add name="FakeSession" type="MyWebApp.FakeSessionModule, MyWebApp" />
</httpModules>
Идем в код и смотрим (using) в пространство имен System.Web и System.Web.SessionState
Создаем Http-модуль под именем FakeSessionModule и реализуем для него интерфейс IHttpModule.
Создаем класс для работы с сессиями под именем FakeSessionState и реализуем для него большие "интерфейсные заросли" IHttpSessionState. Это и будет тот самый экземпляр, доступный из HttpContext.Current.Session.
Заполняем методы и свойства нашего FakeSessionState всевозможного рода заглушками. В общем, чтобы производилась только видимость работы (надо помнить, что наш модуль будет иметь инфраструктура ASP.NET во все методы и свойства).
Теперь остается только воткнуть наш "механизм сессий" в свойство Session, которое только для чтения, хе-хе...
Ничего. Есть статический класс SessionStateUtility, в котором есть метод AddHttpSessionStateToContext(HttpContext context, IHttpSessionState container). Что ещё сказать? Что в первый параметр пихаем наш контекст, а во второй — наш FakeSessionState?
:)