1) Cirrus (codename) doesn't generate any keys. peers generate their own peer IDs. peer IDs are cryptographic hashes of per-peer data that includes a cryptographic public key. Cirrus only performs P2P introduction. it is up to your application and own servers to locate and exchange peer IDs. Cirrus helps peers establish communication once peer IDs are known. FMS/AMS can perform the same peer introduction service.
2) peers on the same WiFi network may have trouble connecting to each other in some circumstances, especially if the NAT is a symmetric NAT and/or the NAT doesn't do "hairpinning", and the web browser hosting the Flash content doesn't allow Flash to see the computer's local (behind-NAT) interface IP address. i believe the Google Chrome Pepper plug-in API currently has this restriction. for best results for same-LAN connections, try to have both peers connect to each other simultaneously.
3) no. Cirrus is a custom-built application that is not currently publicly available -- it is not built on top of FMS/AMS. it was designed to do one thing (P2P introduction) as efficiently and scalably as possible. however, as i mentioned, FMS/AMS also performs this P2P introduction service, and you can deploy and use that today.
4) Cirrus doesn't make a "match". that is up to your application logic and your own back-end servers. Cirrus only helps the peers initiate their communication once they known each others' peer IDs. to get an idea of what's really happening, read Section 3.5.1, and especially Sections 220.127.116.11, 18.104.22.168, and 22.214.171.124 of RFC 7016:
Cirrus is acting as an "Introducer" in those sections' terminology. Cirrus performs both Redirector and Forwarder functions. that's all* it does. everything else is up to your application.
* Cirrus also performs a short message relay service and a group bootstrap service, but those don't appear to be relevant to this query.