Let's see if I can tackle some aspect of your question.
that when this form is completed that Access will automatically generate the top level record (naturally) but also all of the "new" subcomponent records that are incorporated into the form.
Can Access do this automatically? NO - as you asked the question. But YES - if you are willing to help it a bit by flexing in your expectations.
Your description sounds like you went through some work to normalize the tables. Even if they are not perfectly normalized, coming close is good as a starting place. Minimizes the dreaded "retrofit" that we inevitably encounter despite our best intentions. But here is the source of the "NO" in my answer: Access doesn't necessarily automatically create a parent form when you try to create the data existing entirely in sub-forms. If there is a true relationship (i.e. defined in the relationship window), you cannot create child records if the parent doesn't exist. The form/sub-form linkage can't be activated / realized / instantiated if the parent doesn't exist at the time you try to open the linked sub-forms. So you would never be able to fill in the child records - they can't exist.
Unless...
If your parent record includes a primary key that is either an autonumber OR the PK is a "natural" value derived from some attribute of the parent record's subject matter, AND you can manually enter that PK value, then you can link the new child records to the new vestigial parent record. The PK has to be a real, unique number or text field for this to work. If your unit IDs have the potential of duplicated numbers, then of course that ID field cannot be a PK, and Access will NOT allow you to establish a formal independent/dependent relationship with something else unless the independent side has a PK. IF you have an autonumber as a formality to uniquely identify the unit record, though, you can pre-define the unit "parent" record after which the child records can link in.
The problems will be in two main areas:
(a) timing - such that you create the parent well enough that linkages can be honored
and then open the child records. So you might, on creating a new unit record, have to turn off the child sub-forms momentarily to prevent getting caught by the relational integrity trap. (When editing an exist record, this problem does not occur!)
(b) by necessity, the parent record that is created early in this process probably is not fully realized / filled in / whatever it is that it needs done. So before saving it all, you need to go back in fill in any parental blanks. Which means that either what you want comes from the sub-forms or you have these "other" potential parent fields displayed on the main form. Note also that there is an implied DEnormalization if everything you need for the fields of the parent record comes from data in the child records. Because in that case, you have duplicated data in the parent and its child record.
(c) the "Oops" factor - cause by defining a new record and then suddenly realized "Oh, darn, I can't do this yet." So you have to back out of it. If you don't issue your save commands, the child / sub records can still try to save themselves if you navigate or close the form. So you have to do some massive "UNDO" operations on each child record
before navigating away from the record or closing the form. AND there is still that parent record you had to create when you were trying to make linkages for the child records. It also has to be removed since if you don't, you now have an incomplete, childless record floating around just waiting to trip up somebody's reports.
I should also add that you have asked a really good question because this aspect of form behavior is tied up with Relational Integrity principles (specifically, parent must exist before child), and RI issues are getting into advanced design topics. Therefore, good for you that you asked before you implemented. This would have been a hair-tearer really quick. My avatar image is really me, but before I lost all of my hair. So trust me, I know this topic (hair-tearing) intimately well.