How to identify the type of modulation and data rate of an RKE system transmission
Instead of using the very expensive MC9S12XE as you say in your comments, use a microprocessor that's not as expensive, but way cheaper, like the many ARM cortex-M based RF+SDR+MCU systems on chips that you get. For example, SiLabs has a lot of such, but so do TI and Microchip.
Then, you'd try to bend the DSP chain in these to your will, i.e. try out a couple known modulations, and if that fails, try to fall back on a bypass mode where you get direct access to the baseband samples and just process them in software; the TI CC1100 (not really a new chip by any means!) has achieved quite a popularity among radio people for actually being a lowish-bandwidth SDR in a cheap chip.
If you pick your main CPU fast enough for processing many of these modes, instead of trying to shoehorn a strange 16 bit MCU with a lot of very automotive-specific peripherals into a compact handheld device, you will have a better chance of developing something that works.
But seriously,  neither of these approaches stand a chance against

systems that are neither FSK nor OOK (GMSK is arguably not a type of FSK)
you misjudging the pause between non-OOK packets as off-periods in OOK,
frequency-hopping systems (Bluetooth has really gotten cheap and power-efficient).

Regarding your question whether your circuits will work:
I doubt it. They are definitely lacking any receiver frontend, and 0-5V sounds way higher than anyone would sensibly amplify an RF receive signal, so it'll be hard to find a great design for your receiver frontend. You're trying to detect statistical properties of signals with bandwidths in the MHzes, and durations in the higher microseconds to milliseconds.
You will need a bank of these detectors, then some clever method of choosing which detection is most likely true, and to displaying that. In essence, even if you, 1970's cold war signal intelligence style, built a massive expensive detector array, it would be large, and still lacking the hard parts of the actual RF frontend and the actual decision.
So, really, this becomes manageable on a somewhat faster CPU, with a proper SDR frontend. Something like a PlutoSDR running GNU Radio will make you look pretty bad pretty much for half the price in components alone to build a realistic detector array for most of the likely key fob modulations.
Signal classification is a hard job. I didn't mention the cold war (figure from 1984's habilitation &quot; Automatic Classification of High Frequency Signals&quot; by Jondral) without reason: the availability (e.g. 1990's patent) of computing and reception hardware that led to the SDR explosion around the year 2000 is more or less a result of the allied efforts to automatically classify signals. Doing that in discrete analog was too much of an effort, even for nation states. I don't think you'll do a great job designing a handheld device using 1970's technology.