Thanks, this is an interesting question. People are usually trying to avoid forks, not create them on purpose :)
First, when creating the chain you need to ensure that the mining-diversity is set low enough (under 0.5) to enable a long-term fork to take place at all.
At the time of the fork, there need to be sufficient miners on each side of the fork to fulfill the mining diversity requirement. Otherwise one side or the other will get stuck.
When you're ready to fork, prepare a transaction on one of the nodes in one fork without transmitting it, e.g. using createrawsendfrom. And prepare a different transaction on one of the other nodes in the other fork in the same way. Get the txid of each transaction using decoderawtransaction.
Then for the nodes on each side of the fork, use setruntimeparam bantx [txid] to ban one or the other transaction.
Then broadcast both transactions using sendrawtransaction, and each one should be accepted by only some of the network. Wait for miners on each side of the fork to mine a block containing each transaction, and you should see each side of the fork extending.
You should set bantx (and possibly lockblock) as permanent runtime parameters for the appropriate nodes, using the multichain.conf file, so they never adopt the other branch if they are restarted in future. You can also make admin/mine permissions changes to trigger the lockadminminerounds rules. And you should probably change the peer-to-peer port used in each branch, again with runtime parameters, to prevent the two forks connecting to each other in future and wasting time looking at each other blocks.
Note that none of this has been tested, so good luck and let us know how it goes!
