I recall some discussion of the game and watch in a ROM hacking board once. The things aren't actually Turing complete and the "processors" aren't, and in some cases might almost be a stateful input + logic (possibly + clock in some/most cases) rather than actual processing. This makes emulation, from a pure technical sense, not necessarily the correct word and instead some favour simulation.
Ripping sounds depends on what you have to do. If you have a headphone port then that is easy, if not then it is still easy but you get to tap the signal as it goes to the speakers (or maybe DAC if you are really bored and want the very best). If it is a sound generator of some form you could emulate that chip (be it some kind of signals replication like conventional higher end sound emulation or actual transistor level emulation -- if anybody is doing FPGA builds of LCD games then see what they have done as that is a good chunk of the way there).
Graphics wise you have two main choices.
1) Simulate segments, either using some kind of stateful progression like the game itself or an actual emulation like you were writing it as a modern programming exercise.
2) Whole screen. There are a finite and actually rather small number of segments, create bitmaps for each possible combination and call them as necessary.
For 2) you would likely still do a bit of 1) and making every image for every life counter and again for every possible score would be silly.
I am curious about the copyright and trademark implications of these as well. My GB screen is a grid or so many pixels I can program to be any share of grey within a scale, no judge would copyright that. LCD games have artist created backgrounds and the "sprites" themselves are a creative product.
You can also simulate blanking and flicker if you like (I would enjoy reading the equivalent of
http://bogost.com/games/a_television_simulator/ for a LCD game one day).
