I'm not sure I fully understand your exact use case, but: even with reference code inheritance turned on, the quick tests I performed did not cause any issues when intermediary levels had no identifiers.
One interesting thing I did note during my test, however:
I first created my test description in the public demo site. I created a collection with an identifier, a series with no identifier, and then a file with one. With reference code inheritance on and the default dash character used as a separator, I ended up with my file level descriptions having identifiers with two dashes in them (indicating where the missing series identifier would be in the inherited full reference code), like this:
CA REPOCODE COLLECTIONID--FILEID
However, I then exported that hierarchy as a CSV, and imported it into my local Vagrant test box. The import worked fine and all records displayed properly. However, once imported, the empty placeholder dash was gone, so the full reference code was just:
CA REPOCODE COLLECTIONID-FILEID
This was maintained even when I changed the default separator in the Inherit reference code settings.
Anyway, at no point in my tests, admittedly quick, did excluding an identifier at the series level cause an error or bug for me. A couple of considerations however:
First, I did not experiment with including spaces in a single description's identifier and seeing how that might affect reference code inheritance. I suspect it will be fine but might be worth experimenting with a bit.
Next, please note that while it's definitely viable, using slashes either directly in identifiers or as the default separator in the inherited reference codes can have impacts on the search functionality when trying to find records by reference code. This is because the slash is a reserved character in Elasticsearch, the search index that AtoM uses. Not escaping it when searching can cause search errors.
You can work around this by adding the slash as a character to be automatically escaped in searches in the settings - see:
However, this workaround is not perfect either. To learn more, please be sure to read the "Important" admonition text box in the docs section linked above.
Ultimately, the best way to make sure the behavior will work as expected is to run some tests of your own. If you don't want to make test descriptions in your production environment, consider setting up a local Vagrant test environment to play around in: