Ну мне на ум приходит только по названию проверять. А как иначе догадаться, какой класс к интерфейсу подобрать, я не знаю

Да потому что твоя задача в принцыте тупо поставлена и в реалиях не реализуема, потому что не понимаешь сути работы Generic методов.
Иди почитай про DI и контейнеры. Это идеально для тебя

да это невозможно, комон

@gkurbesov про контейнера это не стеб, загугли windsorcontainer

Значит не нужны тебе дженерики, если логика такая

Фабрика или провайдер тебе нужен, а при создании иметь репозиторий, который содержит все объекты. Но это логика контейнеров, Autofac для примера можно попробовать, на метаните есть примеры кода

Аж даже интересно стало. У меня вот такой костыль получился))) Но GetData должен возвращать object. А потом его надо приводить:

class Program
{
   static void Main()
   {
       var manager = new Manager();
       var service = (IService1) manager.GetData<IService1>();
   }
}

public class Manager
{
   public object GetData<T>() where T : class
   {
       switch (typeof(T).ToString())
       {
           case "IService1":
               return new Worker1();
           case "IService2":
               return new Worker2();
           default:
               return null;
       }    
   }
}

Не, точнее даже не приводить, а через is проверять потом надо.

да, тоже думал о подобном, но просто хотел избавится от дальнейшего приведения объекта к определенному типу

Возвращать T не даёт, даже внутри switch не даёт привести результат к T. Безопасность типов - нашевсё

ну если сам хочешь запилить, то лан, подскажу )
Делаешь класс, в нем пилишь два метода и словарь. В словарь <Type, Type>,
Первый метод регает класс, ничего не возвращает, дженерик, во входных параметрах T.
У т берешь тип, и у входного параметра тоже тип и пихаешь в словарь.
Далее во втором методе делаешь T Get<T>
при вызове метода идешь в словарь то тайпу находишь второй тайп, получаешь его констурктор, вызываешь, кастишь к T и все

но легче юзнуть контейнер и все

т.к. с контейнерами раньше не работал сразу встанет вопрос при использовании готовых контейнеров: как быть если классы должны будут создаваться/редактироваться/удаляться налету

во время регистрации можно выбрать  жизненный цикл  объекта

Каждый класс будет реализовавывать функционал TCP сервера для интеграции железа, которое будет передавать данные каждый в своём протоколе.  Пользователи могут в любой создать новый сервер, изменить порт для прослушивания или удалить его

Динамики плохо )

но тут динамика необходима

C dynamic работает

class Program
{
   static void Main()
   {
       var manager = new Manager();
       var service = manager.GetData<IService1>();
       if (service is IService1)
       {
           Console.WriteLine("Service1");
       }

       Console.ReadLine();
   }
}

public class Manager
{
   public T GetData<T>() where T : class
   {
       dynamic worker;
       switch (typeof(T).Name)
       {
           case "IService1":
               worker = new Worker1();
               return (T)worker;
           case "IService2":
               worker = new Worker2();
               return (T) worker;
           default:
               return null;
       }
   }
}

+ параметры всех созданных серверов должны будут сохраняться и при перезапуске приложения - создаваться автоматом

И чем тебе контейнер не подходит?