I just finished a series on the Repository Pattern with the Unit Of Work and Entity Framework 6. This will be a departure from the DoFactory PIA application but you might see similarities because I borrowed many of their features to build my version of the Repository Pattern.
Keep in mind that the Repository Pattern, as I mention in my series, is more of a concept that a strict pattern, which allows you to interpret it as you will. The pattern that I create may need to be tweaked for your application, but that's perfectly OK.
I developed my version to try to keep it as simple as possible and use as many of the features from tools I would be using such as Entity Framework at my disposal. This includes being able to use the DbContext and simple C# classes as my POCO Entities. And using DataAnnotations on my entity classes for validation and other UI helping features. This allows for an easy way to maintain my application when it changes.
Take a look and see if it can help you design your repository pattern for your purposes. http://www.designpatternscentral.net/s/1075.
To answer your question about more than one service or data access repository instance in your controller constructor, this practice is fine and used quite often. To be clear, I mean that the practice of injecting all necessary services into your controller constructor is perfectly fine, but I would always just call some service implementation, and not also data objects implementations. To be maintainable, it's better to always make it a practice to have your client applications, in this case your MVC application, just call any and all services, and not data repositories directly.
You can also find this practice in my series. So yes, it's fine.
I hope this helps.
King Wilder, Sep 21, 2014