Unless you are using 2000i2, you will not be able to create a family table model of the skeleton.
An additional problem you will run into is placing the doors in different positions in different views - you will have to use a different family table assembly model of the aaa.asm to substitute in the different versions of the subassemblies that actually contain the skeleton that you are substituting.
Current
aaa.asm
sub1.asm
skel.prt
sub1.asm
skel.prt
sub1.asm
skel.prt
becomes family table models
aaa_case1.asm
sub1_open.asm
skel_open.prt
sub1_closed.asm
skel_closed.prt
sub1_open.asm
skel_open.prt
and
aaa_case2.asm
sub1_closed.asm
skel_closed.prt
sub1_closed.asm
skel_closed.prt
sub1_open.asm
skel_open.prt
Where aaa_case1 and aaa_case2 are instances of aaa.asm that refer to instances sub1_closed and sub1_open of sub1.asm, which in turn refer to instances skel_closed and skel_open of skel.prt
On the drawing you have models aaa_case1.asm and aaa_case2.asm, and you will not be able to attach balloons from one model on another (only on the model that is actually filling out the repeat region that is creating the BOM balloons).
But like I said, if you used a defined Pro/Engineer skeleton, you will not be able to make the family table instances of skel.prt unless you move to 2000i2. No guarantees on 2000i2 letting you take an existing skeleton model and modify it though, but that's the release that will allow skeleton models to contain family table instances.
As you referred to as well, you will need to set up the skeleton with the family_table_control parameter and layout_control parameter to keep the instances from being modified when people change the layout and affect the generic model.