As your request correlates the terms wildcard domains and DNS, let me just mention that using wildcards with DNS records is problematic.
(In case you are interested why, click for details).
On a conceptual level, allowing definition of wildcard records has the potential to compromise DNS as a delegated system (e.g. a zone that does wildcarding and delegates to a subzone could mess with lookup of DNS records for that delegated zone), potentially breaking DNSSEC.
On a more practical level, use of wildcards has long been standardised in RFC 1034, sec 4.3.3.
It is important to note that wildcards as defined in there differ significantly from what you'd normally expect. Specifically, it would match only for such domains where a DNS record does not already exist, e.g. nextcloud.my.net would not match *.my.net if a DNS record had already been defined for the former.
Ambiguity in RFC 1034 4.3.3 left room for interpretation which in turn led to different DNS servers implementing inconsistent different behaviour for wildcard records. Much later RFC 4592 (still a proposed standard) tried to address this, and today, quite a few DNS servers will allow you to ignore wildcard DNS records from external sources as configured.
But putting terminology aside:
As jfb mentioned, you may be able to achieve what you want by supplying a line to a separate configuration file of Pi-hole's embedded dnsmasq (e.g. /etc/dnsmasq.d/42-reverse-proxied-subdomains.conf):
address=/revproxy.my.lan/192.168.0.42
Note that this isn't exactly wildcarding, as it doesn't involve using wildcard characters at all, and perhaps more importantly, it does not allow a distinction between a domain and its subdomains, e.g. both dig nextcloud.revproxy.my.lan and dig revproxy.my.lan(!) will resolve to 192.168.0.42.
When considering to expose this feature via Pi-hole's UI, you'd have to make sure a user understands this, as providing this at the wrong level may mess up your entire network with one click, resolving all hostnames to a single IP, potentially even cutting a user from accessing Pi-hole's UI to fix this.
To prevent this, Pi-hole could also reject requests for a known local tld, but it may not be accurately aware of that in all circumstances.
Also, DL6ER's remark on longer restarting behaviour and brief DNS outages fully applies here.