By reading this answer, I understand that in m-of-n multisig addresses, m and n are limited by the maximum size allowed by the P2SH redeemScript (i.e. 520 bytes).
That's correct. Even though the OP_CHECKMULTISIG script opcode supports more keys, more than 15 public keys simply don't fit in a P2SH redeemscript, so that becomes the limiting factor.
However, in this section of BIP141, it is stated that the witnessScript can be as long as 10,000 bytes. As far as I understand, this implies that with SegWit adoption it should be possible to create and use m-of-n multisig addresses with very large m and n that will be considered valid.
BIP141 only describes the consensus rules - i.e. what transactions are valid inside blocks. There are a number of standardness rules that apply for transactions to be relayed and accepted into memory pools, to avoid potential avenues of abuse before they're understood. Bitcoin Core 0.13.1 and up limit witness scripts to 3600 bytes for that purpose.
For instance, would the following witnessScript, which should represent a 50 out of 100 multisig address, be considered valid and spendable under SegWit?
0x01 0x32 <100 signatures> 0x01 0x64 OP_CHECKMULTISIG
I assume you mean public keys there instead of signatures?
No. OP_CHECKMULTISIG itself only supports up to 20-of-20, so if you want to use that opcode, you can't go above 20. However, you can construct others scripts that go above those limits.
In particular:
<pubkey1> OP_CHECKSIG
OP_SWAP <pubkey2> OP_CHECKSIG OP_ADD
OP_SWAP <pubkey3> OP_CHECKSIG OP_ADD
...
OP_SWAP <pubkey67> OP_CHECKSIG OP_ADD
<m> OP_NUMEQUALVERIFY
would implement an m-of-67 policy, with less than 3600 bytes.
