You should separate the code dealing with the web services (i.e. sending and receiving data) from the code processing the results. Move the latter code into a distinct class, making the necessary methods public. Then you can easily unit test the processing logic, in isolation from the external dependencies.
By this, you also make your code conform to the Single Responsibility Principle. As a general rule of thumb, feeling the need to test private methods is often an indication that the class has too many responsibilities, thus should be refactored into multiple classes.
Please note that I only have minor experience with the .NET framework and that this answer only relates to the architecture part of your question.
As far as I understood it, you are basically applying the following architectural patterns in your application:
Layers: It seems you have a persistence layer (Repository Pattern), a business logic layer and a view layer.
Model-View-Controller: This pattern is applied in the view layer using ASP.NET MVC.
I guess the question is: what does a BLL look like and what does the MVC controller that uses it look like?
First of all, this architecture is intended for large-scale, enterprise applications as Robert Harvey mentioned in his comment to your question. What is characteristic for such systems is that the domain logic (which you encapsulated in the business logic layer) should be accessible through various interfaces.
Consider Twitter for instance - Twitter could have a business logic layer which provides services for registering and validating users, posting tweets and much more. On top of this business logic layer, multiple other components could exist in the view layer, e.g. a web interface and web service component. Since all business logic is encapsulated in the business logic layer, you can follow the DRY principle and improve maintainability and other quality attributes.
To come back to your question - you should encapsulate business logic and data access in the BLL. The controller (think MVC) should make use of the BLL and should not have direct access to the database. Consider the view layer as an interface to your application.
So I feel like if I have a BLL, I should be passing it the IUnitOfWork, so that it can use that to create the IRepository instances that it needs. But how will the BLL (separate DLL from the front end) 'know' what implementation of IRepository to build?
The BLL should know which repository (data source?) it uses. The layers above shouldn't control this. Again, consider the view layer only as an interface to your business logic.
If you don't need the overhead of a business logic layer, you may also choose to use it solely for data access in form of data access objects.
I hope this helped clarifying the various components' responsibilities.
Best Answer
I don't think there's much point. A Repository is supposed to act as a layer of abstraction between your business logic and the database, so by the time you mock the database for testing purposes, all that's left to test is the Repository's API endpoints (a test that I would regard as "uninteresting", and already covered by integration tests anyway).
Of course, depending on what you consider "enough." This is the appropriate place to mock a business operation, in my opinion, since the expected values are those required of your repository mock, and not those of a database (which would require an integration test).
To put it another way, your repository is already expected to return the "correct" value. If you're not sure about that, then include some integration tests for your repository (wired up with the proper data-source) to make sure.