The thought did cross my mind when I replied earlier, but I wasn't sure about letting an implementation detail of the HTTP request lifetime scope escape out in the desktop world. It would certainly work though, and creating an extension method for this would isolate the use of the special tag to one location. You would also have to make sure that the lifetime scope in the desktop application that the parent services will be resolved from is created using the same tag. Again, you would want to keep the use of the special tag in a single place.
I would probably start with InstancePerHttpRequest for your controllers, and use InstancePerMatchingLifetimeScope for the other shared services. If you don't have complex lifetime management requirements (such as many levels of nested scopes) you will probably be fine. You can always move to using the special tag later if you find it becomes necessary for some reason.
In regards to unit testing the registrations, are you wanting to assert that the correct lifetimes are applied to the services via the registrations, or is the question more about mocking the lifetime scope when no HTTP request is available?
What about if I used
InstancePerMatchingLifetimeScope(<asp.net lifetime session>) instead ?
Would that work any better?