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:

non-segwit:

byte
count   field name
4       version
1-3     varint of number of txins
32      sha256d of previous transaction

segwit:

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.