Inside an OSGi environment this is already possible. In fact this is already tested inside the integration tests.
The WhirrServicesTest under platforms/karaf/itests does exactly this:
Inside a vanilla Karaf instance it registers the a descriptor which defines the artifacts required for running whirr & its services (split in logical groups: whirr, whirr-zookeeper, whirr-hadoop etc). Then it installs to the container one by one and makes sure that whirr can discover and use any of the services.
This can be applied to any OSGi environment and not just Karaf.
Now, lets think outside OSGi. There are two things needed. The first is dependency resolution and the second is dynamic registration.
Dependency resolution: Even with the use of a tool like Aether or Ivy (I am only a bit familiar with the first) no one can guarantee that the resolution will succeed as it will require that the maven metadata reflect 100% the runtime requirements (its not always the case) and of course that can't prevent conflicts (maybe isolation will help here).
Dynamic Registration: Yes dropping jars to the lib will work and its a fine approach when you are dealing with the CLI. You can even add some commands for adding new services by referencing a descriptor or something. If we are talking about whirr as a library, which is going to be used inside a java application, container etc, then it gets a bit more complicated. I think that the SPI approach will have issues if the class is not in the class loader hierarchy and that could be a problem if you are loading services isolated. Maybe commons discovery & some TCCL can do the trick.
This is exactly why I love OSGi.