RFC 1035 defines the NS resource record (RR) merely as a domain-name without specifying the RR type of the target (though it does make it clear that it can't be an IP).
RFC 1912 has more specifics, in section 2.4:
Having NS records pointing to a CNAME is bad and may conflict badly
with current BIND servers. In fact, current BIND implementations
will ignore such records, possibly leading to a lame delegation.
There is a certain amount of security checking done in BIND to
prevent spoofing DNS NS records. Also, older BIND servers reportedly
will get caught in an infinite query loop trying to figure out the
address for the aliased nameserver, causing a continuous stream of
DNS requests to be sent.
As was later pointed out in the comments, RFC 2181 Section 10.3 has a clear prohibition against this:
MX and NS records
The domain name used as the value of a NS resource record, or part of
the value of a MX resource record must not be an alias. Not only is
the specification clear on this point, but using an alias in either
of these positions neither works as well as might be hoped, nor well
fulfills the ambition that may have led to this approach. This
domain name must have as its value one or more address records.
Currently those will be A records, however in the future other record
types giving addressing information may be acceptable. It can also
have other RRs, but never a CNAME RR.