PashaPash

class Program
{
  static object ReturnAnonymous()
  {
    return new { Name = "aaa", Number = 123 };
  }

  static Func<T> Cast<T>(object obj, T type)
  {
    return () => (T)obj;
  }

  static void Main(string[] args)
  {
    object o = ReturnAnonymous();
    var getAnonimusInstance = Cast(o, new { Name = "", Number = 0 });

    var a = getAnonimusInstance();
    Console.WriteLine(a.Name);
    var b = getAnonimusInstance();
    Console.WriteLine(b.Number == a.Number); //где a и b имеют анонимный тип, описанный выше.
  }
}

* This source code was highlighted with Source Code Highlighter.

Написал до уточнения про 3.5, адаптировать лень.

Пример с БД не слишком очевиден без кода. Непонятно, зачем было перечислять интерфейсы в бизнес-логике. Наверняка можно было попробовать что-то вроде IoC/DI и рефлекшна для регистрации всех интерфейсов в IoC контейнере.
Решение с Tuples хорошее. Но хотелось бы понять, какую конкретно архитектурную проблему оно решает лучше, чем остальные методы.
Предлагаю подождать комментариев в хабратопике.

В текущей версии C#, с сохранением строгой типизации — никак. C# не позволяет наследоваться от generic-параметров. Что-то вроде interface IDoubleInterface<I1, I2>: I1, I2 {} не заработает. Без генериков — строгой типизации не будет.

Не уверен насколько ситуация из P.P.S. жизненна, но в ней проблему связности нужно решать на другом уровне.
IMO, не стоит даже думать об сегрегации интерфейсов отдельных элементов управления, если каждый контроллер при этом получает форму с 50-ю полями, и может творить со всеми ее элементами что угодно. Попробуйте выделить интерфейсы из самой формы — возможно, многие контроллеры вообще не пересекаются по используемым свойствам.