The answer comes from the Facade pattern.
What you need is a facade to an IRepository<T>. This is where I would create an ITRepository (ICustomerRepository) for instance that implemented IRepository<Customer>. Then I would also create a concrete Repository (CustomerRepository: Repository<Customer>, ICustomerRepository). There's no more code to write seeing as everything is done in the base concrete and interface (Polymorphism, encapsulation, inheritance). Now I have the option of registering my services as such:
builder.RegisterType<CustomerRepository>().As<ICustomerRepository>();
Job done. Now my controllers just take the ICustomerRepository and can still store it as an IRepository<Customer> seeing as it is one.
The next problem that I have with DI is that DI is a website concern and not a Service concern. The service doesn't care which IoC container to use and why should it. It just exposes the interfaces, concretes and in this case the Controllers that it uses to do its job. Therefore any services need to be registered in the Web Application. What happens if you decide Autofac isn't working out any more and you want SimpleInjector or Ninject? You don't want to go through every single one of your plugins rip out Autofac (via nuget), put in a new IoC container and reimplement everything. That's just painful. So you should inject everything in your web application. Which provides a new interesting solution. This will mean that you pull in your dll's from plugins into your website. Now IIS and System.Web has your files and knows what to do with them (such as routing). All of a sudden you've got rid of a LOT of code.
Let me know what you think in the comments.
Matt