Yes, to make "megablocks" viable for anything besides block chain data storage, the sigops limit would need to be changed. Simply increasing it would be the easiest option, but I suspect at least some developers would prefer to change how the sigop limit is calculated instead.
ECDSA signature-checking operations (sigops) are relatively time-consuming on moderns CPUs, so the goal of the sigop check is to make it easy to reject blocks (valid or not) that could otherwise take a significant amount of time to verify. The sigop check is implemented naïvely: it simply looks for the OP_CHECKSIG and OP_CHECKMULTISIG op codes in transactions and calculates the number of sigops that will be required should that code be executed. The aggregate number of sigops is calculated for the block containing the transactions.
You may have noticed the problem: for scripts like P2PKH, OP_CHECKSIG can appear in one block as a pubkey script but the actual time-consuming signature checking operation takes place when the signature script is evaluated in another block. In other words, it's possible to create a valid block today that requires performing more than 20,000 signature-checking operations but which has a sigops count of 0.
If we have to hard fork in megablocks, I think it possible that the opportunity will be taken to also change the sigops calculation formula---or to replace it with something different.