Backup-liveness-connection is optional and has always confused me as well. Unfortunately, the documentation is clear as mud on this subject. See here (FYI if you select the CLI Explorer re-direct, you'll just end up in a loop!):
https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/backup-liveness-detection-edit-protocols-iccp-peer-qfx-series.html
Basically as far as I know it is just a second connection between the nodes other than ICCP/ICL to test if other node is up or not. Therefore additional protection if ICCP goes down. A better solution, IMHO, is to put in additional redundancy for ICCP/ICP. I always recommend these be put together as part of an AE that is split HW wise across different modules. Requires at least 2 faults to physically have this link go down.
Yes, FXP0 can be used for this - most common method?? I think so. As for learning within OSPF, I'd think no. Just need communication across this link between the 2 nodes.
As for interface mac, I'd suggest you use either:
show interface extensive (look for hardware address)
or
show interface ge-x/y/z extensive | match hardware
This should work for both physical and logical interfaces
Just FYI for anyone reading this article, Juniper is moving away from MC-LAG as one the preferred solution, to instead use EVPN/VXLAN (or MPLS depending upon product) almost exclusively. If you have a greenfield deployment, I might suggest it is a good idea to consider an EVPN based architecture, or at least consider this technology.
Good luck, HTH.