I am asking if this is a correct implementation of this pattern or is there a better way?
Not exactly. Your service locator, in an ideal scenario, doesn't depend on any interfaces - it's just a dumb container/map/factory. Something (reflection, manual coding, inheritance, some serialized form, etc) populates it, and then when consumers ask for an instance that satisfies some arbitrary interface, the service locator provides it. Depending on how it's implemented, it doesn't even depend on data - its consumers tell it where to go.
In an enterprise architecture, where is Service Locator most appropriately used, and why?
All that said, the service locator is commonly viewed as an anti-pattern since the contract it supplies (you ask for an arbitrary interface, I give you an instance that satisfies it) is very broad. It tends towards being a God Object. It tends to be a bit fragile since errors in use only show up at runtime.
Those downsides are true, but anti-pattern implies it always produces badness when used. That is not the case in my experience.
Service Locators are useful when you have many, dynamic components that need to be resolved at runtime - components that will vary depending on the context you're working in. For example, I've seen it used when emulating a variety of hardware devices, each with their own configuration and capabilities. It was just as easy to unit test as IoC containers, had similar runtime errors, but supplied the necessary flexibility that IoC containers could not.
But that sort of scenario is exceedingly rare. In general, having that sort of arbitrary type lookup isn't worth the cost.