Just to be clear, we’re dealing with internal DNS here. No registrars
are involved. I don’t know much about registrars/delegations but I think
it applies mostly to public domains?
Yes, but the DNS is a coherent global namespace, so for internal DNS you
should use a subdomain of a properly registered public domain, e.g. we use
private.cam.ac.uk.
There's a fundamental conflict between DNSSEC (which proves that
unregistered names do not exist) and internal DNS that squats on fake
domains. There's also a risk of conflict with ICANN's new gTLD programme.
It was common to get away with fake internal domains in the past but those
days are long gone.
It's problematic that Consul's defaults guide its users to make this
mistake. I think it should configure its domain option based on the
Consul server's FQDN, rather than using an unwise fixed value.
Idea, can Unbound not “vouch” for (trust) this zone DNSSEC-wise and
reply to other DNS servers with correctly signed responses?
You can kind of do this, but not with Unbound. You need an authoritative
DNS server that supports DNSSEC, which can sign the internal zone. Then
you need to distribute the trust anchor for your internal zone to all the
validators that need to access it. But your authoritative server is
Consul, which does clever things not including DNSSEC, so this way would
lead to a lot of unpleasant complexity.
One thing that does work is going straight to Unbound, but the question
is how to make our internal DNS aware of that and “redirect” the client
to it (without listing the Unbound server in /etc/resolv.conf). So is it
possible in the DNS world to reply to the client with a “referral”
instead of doing anything recursive for it? As in "if you’re looking for
“something.consul.", go to this DNS server. I won’t do the recursion for
you.”?
That's how the recursive -> authoritative part of the DNS protocol works,
but not the stub -> recursive part. Stub resolvers need to get a complete
answer, they aren't clever enough to follow referrals. But what you might
be able to do is get your client machines to talk direct to Unbound only,
and configure Unbound to forward internal queries to Consul and other
queries to BIND. (I didn't suggest this before because I thought you said
they have to use BIND as their recursive server, but I might have
misunderstood how strong this requirement is.)
Sorry for the silly DNS questions!
No problem, this is a legitimately murky corner, so the questions aren't
silly. Fake internal domains, on the other hand ... 
Tony.