Can't be.
Your (visual) object(s) might /be contained in a BG/, but it surely
ain't a BG itself.
BGs don't make for visual objects, so they'll inherently be
unpickable, since you can only pick what you're able to see.

That's obvious.
Have a look at the API-Dox for BG and S3D and the hierarchies:
BG: jl.Object -> SGO -> Node -> Group -> BG
S3D: jl.Object -> SGO -> Node -> Leaf -> S3D

How should a cast from a Group to a Leaf be done?

Exactly. BGs aren't Shape3D()s or even Geometry()s and don't
contain any displayable geometry information.
They are just containers for other items, such as TransformGroups,
Shape3D, Geometry, Behaviors, Bounds and so on.

Have a look at the demos PickTest and PickText3D to see how picking
can be done.
Maybe, you'll even want to have a look for the J3D-Tutorial that
comes in the seven pdfs named
"j3d_Tutorial_ch0.pdf" .. "j3d_Tutorial_ch7.pdf" and have a more
or less short glimpse at it to familiarize a little with J3D.

At the appropriate geometry node(s) that contain(s) the geometries
you want to pick.
Hint: if you surround the offending statement with a try-catch-clause,
you might be able to get additional information about *where* the
error lies in your catch-code.
Use the .setUserData() to assign unique IDs to your geometry nodes
and have this being print out when you are trying to perform your
picking.

try {
do_perform_pick();
}
catch (CapabilityNotSetException CNSE) {
System.out.println("CNSE: "+CNSE.getLocalizedMessage());
[retrieve and dump additional information]
}

This'll keep your code from crashing and enable you to examine any
object you want to. But it won't fix your problem - it might just
assist you in tracking it down.
Maybe, you'll also want to use a debugger, single-stepping and some
breakpoints. At this point IDEs like eclipse come in very handy.

No. Why should there be such?

Regards,
André