Color me Mr. Skeptical, but I doubt that there's anything in the LC's ROM that has anything to do with the 16 bit bus width. (Other than *possibly* some device driver handling code but I'm not going to get into that other than note that open-source *nix authors have discovered when porting Linux/xBSD to the 680x0 Macs that Apple was sometimes *incredibly* lazy with how they implemented bus decoding; it's possible there are devices in the LC that are not transparently handled by the process I'm about to describe.)
The 68020 and 68030 have hardware support for "Dynamic Bus Sizing"; there are a couple *input* lines to the CPU (DSACKx) through which an external device (be that a memory mapped peripheral, RAM, whatever) can automatically signal whether it's 8, 16, or 32 bits wide thereby instructing the CPU will use an onboard multiplexer/buffer to split up the read/write operation into a suitable number of bus cycles. (Information on this is in the 68030 user manual, you can look it up.) This process is completely transparent to software running on the system, and I am 99.44+% sure that the memory controller in the LC handles all the work of signalling the CPU to switch into 16 bit mode when it accesses the RAM area. In fact, I rather doubt there *is* a software command you could give the 68020/30 that would force it to mask out a whole area to be accessed at X bus width *without* setting the hardware up appropriately.
In fact, you can basically prove that the LC/LCII is using the dynamic bus sizing just by looking at the block diagram in the developer note. (Unfortunately I could only find the Devnote for the LC II, which concentrates only on the few differences between the systems; the straight-up LC Devnote probably explains in detail how it's using DBS.) Note how data lines *16 through 31* connect to RAM via a set of 74245 buffers, not 0 through 15; as explained in the 68030 manual it's the uppermost address lines that are used for any given bus size. (IE, if you throttled the bus down to 8 bit you'd use 24-31, not 0-7. And in fact, if you look at the block diagrams you'll see the SCSI and SWIM chips, 8 bit peripherals, are indeed hung off of those lines.) So what does this mean for the prospect of trying to double the RAM size by paralleling another set of RAM chips onto the bottom 16 bits of the CPU data bus? Well, it means that unless you were to cut the DSACK lines loose from the stock memory controller and insert a circuit that would instead generate signals indicating a full 32 bit bus width was available when the CPU addressed the RAM area the system would *completely ignore* your pasted-on memory.
Switching over to the Classic II devnote, since I can find that, I see another possible problem. It looks to me as if the onboard memory controller is actually physically mapping all 10MB of the possible RAM into a linear block from $00000000 to $009FFFF; unlike the "Real" Mac II family, where the SIMM socket addresses are scattered over a huge addressing range and the MMU is used to collate all the physical memory together into a linear block the Classic II and LC/LCII appear to do that in hardware. Here's the problem with that: If you did hack DSACK and parallel on another RAM bank then instead of RAM cutting off at the 10MB mark it'll cut off at the 20MB mark... and therefore land right on top of where the video, ROM, and expansion areas are mapped in 24 bit mode. This would be a *physical* contention, not a "logical" one. So, yeah... that ain't going to work.
Short answer is it seems to me you're not going to be able to do this without essentially replacing the onboard RAM controller. (Which is essentially what a board like the Presto Plus does.) Frankly it seems like you'd have better luck just hanging another bank of RAM off the PDS slot and using a low-level device driver to instruct the system's MMU to map that memory contiguously after the 10MB onboard when the system is in 32 bit addressing mode. (Which the Presto Plus may well also do.)