I don't know whether you could achieve what you want using standard dm Server JPA support, so I'd be interested to know why you think that isn't sufficient for your application.
But, if you need to, yes, you could probably get a lot of benefit if you are willing to depend on dm Server internals.
To understand the overall structure of the deployment pipeline, take a look at the Plumber class which builds the pipeline. Each artifact which is explicitly deployed (rather than provisioned in order to fulfill a dependency) is passed through the deployment pipeline. The artifact is represented as a tree. In the case of plans, this tree is "resolved" fairly early on so that each member of the plan is a child of the plan node.
The main extension point of the deployment pipeline is obtained by publishing a Transformer service in the service registry. A Transformer is passed the top-level Tree of InstallArtifacts which is being deployed. It can traverse the tree and make fairly arbitrary modifications, such as adding nodes (perhaps you might want to add a bundle).
The main consideration for Transformers is that of interaction with other Transformers. Transformers are driven in the natural order of their services which is determined by service ranking and service id. The usual ordering gotchas apply: take care if you must be first or must be last in the ordering as you may end up conflicting with another Transformer that believes it has the same requirement.
The Plumber class is defined in the com.springsource.kernel.deployer.core.internal package and the Transformer interface is defined in the com.springsource.kernel.install.pipeline.stage.tra nsform package, both of which belong to the kernel's deployer project.
Please feel free to post back here with more questions We'll be able to give you a bit more attention once we've shipped 2.0.