I made some progress -- it's not possible in macOS to create network interfaces with arbitrary names, what they can do is based on their names -- e.g., all bridges MUST be called "bridgeN" for integer N. All ethernet interfaces with associated hardware are called "enN" (and if there's no hardware you can't make them).
However... there are "fethN" interfaces -- or "fake ethernet". Feths function in pairs - you can, for example --
ifconfig feth0 create ether 4a:d7:05:c0:ea:00
ifconfig feth1 create ether 4a:d7:05:c0:ea:01 peer feth0
ifconfig feth0 up
and packets transmitted on either feth interface will arrive on the other. You can't peer a "feth" interface with a real "en" interface. You *can* add a member of a "feth" interface peer as a bridge member - but it looks as though bridge groups have member compatibility restrictions -- if you add an enN interface first you can't add a fethN interface, and vice versa.
I haven't looked to see what happens if you, say, create feth0, feth1, feth2, DON'T give them peers, but add them to a bridge group -- that might be the ticket to getting more than two Lisp images talking to each other, though even the case of only two (peered feths) is a minimal workable experimental setup. What this doesn't get you is the ability to get the feth packets out onto the external ethernet interface.
On FreeBSD, I believe the "feth" functionality is provided by the "vmnet" (and "tap" and "tun") driver, and on Linux it seems to be the veth driver -- though it looks more complicated there (and doesn't use the same ifconfig commands to manage it).
% ifconfig -C
(macOS:) rd feth bridge bond vlan pflog gif iptap pktap
(FreeBSD:) bridge wg vlan vmnet tap tun lo gif usbus wlan
So... no real show-stoppers, I think.