The answer here is "more or less, but with some work". Ideally the DAC framework is intended to model an entire database but can be configured in a number of ways to overcome this.
One way is to ensure "drop objects not in source" is set to false in any publishing configuration. This is in the advanced publish settings and can be configured on the command line etc. The downside of this is that when you delete an object in the dac schema it won't be dropped in the
For a more complete solution you would need to use a deployment contributor to filter any steps relating to schemas other than "dac". The starting point is "Solution 2: Filtering at deployment time" in the DacFx tutorial I wrote (source code here). This shows how to filter out Create steps - you'd actually want to extend that to drop steps too. The benefit is more control and a better match to your solution, the downside is needing to write some custom code and include that in your setup.
Note that whatever you do, you'll still find that schema compare and other tools show the alternative schemas. You can configure schema compare to filter out those other schemas, and save the comparison file with those settings for use in the future.
In addition, you do need to be disciplined about not having references to the other, manually managed schemas from dac schema. There is support for writing custom code analysis rules to enforce this, or you could just enforce it through code reviews etc.