I'm also a firmware engineer.
Sometimes, the only way progress can occur is to have someone ignore the knowledgeable greybeards who say something "can't be done", and try to do it anyway.
This isn't one of those times. I've done firmware for 20 years, and I'd guess that I have a better chance of winning the lottery than making this work. Your chances are even lower.
Modify tables in the Firmware? Possible, if you have the right knowledge, insight, software, and equipment. You can generally look at a hex dump and find data tables easily, if you have the knowledge and experience to know what a data table is, and have looked at enough memory dumps to intuitively know what they look like.
Modify code in the firmware? Unlikely. I've patched Windows executables before, to bypass date checks in time-limited demos or remove limitations related to whether one is running a Server or Workstation version of an OS. The only way to do that is with a debugger that'll single step assembly without any source code, but it's possible. Fortunately, Microsoft always used to include Debug.exe with everything back to at least DOS 2.x.
You'd have to identify the processor used in the particular DVD drive you're interested in. Easy enough; read the markings on the back, and Google it. Find a disassembler for the instruction set used - google might find you one. Download the firmware from the drive. Don't know how? Neither do I. Best case, you find a utility that will do it for you; worse case, you have to desolder the flash chip on the board (or the processor, if the flash is internal) and stick it into a programmer to read it out. Worst case, the firmware is internal to the processor chip, and the security bits have been set keeping you from reading it out.
Use your disassembler to get an uncommented assembly listing of the code, say, 50,000 lines of assembler. That would be about 200K of assembled code, about right for the size of Flash I've seen on some drives. Identify functions, try to determine what they do, give them meaningful names. Try to identify how the hardware is configured based on how the firmware controls it - does OUT 0x100, 0x04 cause the head positioning circuitry to step, cause the motor to speed up/slow down, turn on an LED, or what? It would be best if you have the datasheets for all of the other chips on the board to help you guess here.
After 6 months of work, you'll probably have about a 60% complete, annotated listing. You can now probably start figuring out how the firmware reads data off the disk, and might be able to follow how it figures out what kind of disk is in the drive. You'll probably need all of the CD and DVD specification books (Red book, orange book, etc) to figure this out. You might be able to figure out what it will read from an HD-BURN disk. Then, you need to write all new code to parse the data structures and directory order on disk, and to correctly respond to commands from the host computer. And, you have to write it all correctly and perfectly, because you most probably don't have any way to run the code in a debugger.
You then run your code through a processor-specific assembler, create a Flash image, and program it into the drive. Turn the drive on, and see what happens.
Good luck
/frank
p.s. Your better bet is to get involved with some existing project that's hacking firmware on a commercially available project. For example,
http://www.rockbox.org/ is a project that completely replaces the firmware in an Archos hard-disk based MP3 player. Getting your feet wet with something like this would get you started on the learning curve.