I've been doing a little research on the issue, specifically with the BC296D. Given the litigious nature of corporations these days, publishing findings, even done without the benefit of any inside information, is something of a risky proposition. But theoretically speaking, I do believe it is possible, if maybe not completely feasible.
First of all, the firmware is distributed within the Uniden firmware update downloads in S-record format, but if you were to convert the S-record file to a binary file and look at it in a hex editor, you might expect to see (for example) the text strings that make up the extensive menus. However, you won't see the strings. The bytes in the S-record file have an offset applied to each byte that obscure the data, and these offsets appear to be slightly different for different areas of the firmware. I am not sure why this is done, but I can confirm that this is the case. (Please note that this is not a form of encryption. It is somewhat akin to obfuscating a message by using the next letter in the alphabet, for example, by writing TDBOOFS instead of SCANNER.) Now, with that being said, there is software available that will log all data received and sent by the serial port to a file. If you run this software while doing a scanner firmware update, you will see the transformed S-records sent to the scanner with the offsets removed. If you take this S-record data and convert it to a binary file, then it is easy to see the strings in the clear and know that the data is in its correct intended format.
The processor type, as mentioned, is known; at this point, if you have access to a disassembler and the will and fortitude to figure out how the firmware works, you could theoretically figure out how the BC296D firmware works. This is a huge job and is probably a futile exercise. A better strategy would be to figure out how the microcontroller interacts with each of the peripherals (keyboard, LCD display, scroll wheel, various DDS synthesizers, etc.). The processor in the BC296D has a number of general purpose I/O ports whose inputs and output control many of these peripherals. So, if you were to look for those portions of the code where the GPIOs are manipulated, you might be able to make some educated guesses as to which port control which peripheral and how it's done. You will need good deductive reasoning skills, a lot of trial and error and a lot of luck.
If I were to perform the procedure, the first place I would start would be with the firmware update procedure, for two reasons. First of all, if I were going to modify the firmware to patch portions of the code in order to test out some theories and upload it to my scanner, I would want to make absolutely sure that whatever I did wouldn't hinder my ability to upgrade the scanner in the future, or, worse yet, render it inoperable forever. The processor in question has some amount of flash memory in which the firmware and the firmware update procedure (accessed via the L/O-SCAN-6 keypad combination) resides and I understand that parts of the flash can be locked and prevented from being rewritten. One would have to be very careful with this facility when modifying the contents of the scanner. Secondly, this would be a great starting point to figuring out how the keyboard is accessed. You know that one of the first things that the firmware has to do is to see if L/O-SCAN-6 is depressed, and if so, enter the firmware update procedure. I would imagine that you'd see some ports being accessed to check for certain values and dispatch either to the firmware update procedure or to normal scanning mode. Tracing through the disassembly requires a lot of careful notetaking, researching how the microcontroller reacts to certain instructions and it's a not an exercise for the faint at heart.
Perhaps the best way to conduct experiments is to modify the firmware such that before the scanner goes into regular scanning mode, you have a chance to read and write the RAM and/or SFRs on the microcontroller and execute code in RAM by writing data to the serial port. You could then write programs with your assembler, store the bytes in RAM by uploading them through the serial port, and then executing the code. The benefit here is that you don't have to modify and upload the firmware every time you wanted to run some code. (Just make sure that you provide a way to get back to normal scanner mode.)
It would take a concerted effort by a large group of individuals cognizant in embedded systems and assembly language to figure out how the entire BC296D firmware worked. I don't think we will ever see this. However, I do not doubt that a few tenacious individuals would be able to at least figure out how to tune a station, read the keyboard and access the display and maybe create some experimental firmware that showed off these concepts. You're never going to see a completely fully-featured replacement for the original firmware.