Disclaimer: I have not built an application with a microservices architecture, I'm simply using my intuition here, and what I consider being mostly common sense.
I believe that trying to manage this on the front-end is overkill. I would recommend that you build a backend for your single page application, which knows about which microservices are available or not (be it by checking user credentials like you mentioned, or the service being down for maintenance, etc), and that will orchestrate everything. I would call this the application layer, which glues everything together, and acts as a facade to access your different microservices.
Your SPA does not need to know that it's getting its data from microservices. It should definitely request the data from a single entry-point, which dispatches the queries to the appropriate services.
If you're building a single page application (SPA), then you probably don't need the "MVC" in ASP.NET MVC. Views, especially dynamic views, are likely delivered/manipulated client-side. Angular handles that just fine.
But maybe you don't want a 100% SPA. Then what? Imagine instead 10 pages, but 10 pages that are very dynamic. After a user logs on, there's a little user badge up in the right-hand corner. That's not dynamic. It just shows a few nifty things like the user's "score" and their latest selfie. You cache the nifty things so they can be easily retrieved. Now, you can go two ways with this. If you're a client-side MVC purist, you just fetch the badge data after the initial HTML payload is delivered, just like all the other data. But maybe you're not a purist. Maybe you're the opposite of a purist. Maybe you're an impurist. So, instead of delivering the initial HTML, delivering some JavaScript that will post back to your server, post via JavaScript to grab badge data, and then ultimately merge that data into a view via client-side MVC, you simply decide to merge the data already in your cache into a view on the server and then deliver that as your initial HTML. After your initial HTML is delivered, you proceed with your typical client-side MVC antics.
So... MVC on the server and on the client is just a convenient way to organize code that used to be a mess in 2001. You don't have to choose one or the other. You can choose both. Granted, the more you do after that initial HTML is delivered, the less you need server-side MVC. Still, it's there for you if you need it. For example, I worked on a ASP.NET MVC/Angular application where external Angular templates might actually be .NET MVC ActionResult. That means your server controller could merge data into its view, deliver it to Angular as a template, and Angular's controller could then merge its data into the view. I'm not saying this is a good idea, but it just shows that one form of MVC doesn't make the other obsolete.
Besides, no matter how you deploy Angular, you're going to need a way to deliver that initial HTML, the templates, and most importantly the data. Why not use a platform that makes it easy? There are many, but .NET MVC is no slouch. Like I said, you can make the initial HTML and external Angular templates the result of an MVC action, but better yet, you can use .NET'S Web API to deliver the data. Web API is as delicious as apricot compote.
Summarized: MVC is just a pattern. You may want to use that pattern on any number of physical layers. It can't be used up. Use it freely if it makes sense. Besides, Angular may not be MVC anyway (so says people who care about these things), so feel free to use it with a tool that has "MVC" in the name. Hell, even if it is MVC, mix and match as desired.
Best Answer
Angular 2 is not yet released, it's at release candidate level though. If I were to start a new application today I would seriously consider just going with it. If you are building something large, the release will probably catch up.
AngularJs 1.5 will have more 3rd party add-ons though, more example code, howto's etc. There is some 'forward' support allowing you to make a hybrid. See https://angular.io/docs/ts/latest/guide/upgrade.html
Angular 2 will be enough of a change to make a lot of knowledge about version 1 obsolete.