...or is there any way for a SegWit witness to contain a "legacy" signature?
I don't think that's possible, even if you intentionally construct the transaction to be used as both segwit or non-segwit, and if you assume that there are segwit and non-segwit outputs for the same address.
The first ~36 bytes of a hashed transaction look like this:
byte count field name 4 version 1-3 varint of number of txins 32 sha256d of previous transaction
byte count field name 4 version 32 sha256d of concatenated prevout fields
You would need to find two pieces of data such that
hash(x)[1:16] = hash(y)[0:15] or
hash(x)[3:16] = hash(y)[0:13], which I think is about as difficult as a collision attack (to a factor of 2^24 :P).
You can try to get around this by setting SIGHASH_ANYONECANPAY on the segwit side, but that puts a zero where the number of inputs should go on the non-segwit transaction, and that's definitely not valid in any signature mode. I think even if you sign in SIGHASH_NONE, you can't convert a segwit transaction to a non-segwit transaction, or vice versa.
No, it cannot. There are several reasons this won't work. For example, the signatures in Bitcoin transactions commit to the complete transaction by means of signing the sighash. However the sighash is formed by a different scheme in SegWit than for legacy transactions. Another is that SegWit transactions contain elements that are not present in regular transactions, namely marker, flag and witness. Thus even if sighashes were using the same scheme, the content that they commit to could never match up.