If you are only interested in the opc connection & you have an opc server you don't need a plc, OPC servers usually work in two ways, you create the list of variables in the opc server i.e. Valve_open = Address M249 so the opc server contains all the addresses, your client (HMI) only refers to the namespace i.e Valve_Open.
The other way some opc servers work is that the addresses & namespaces are configured in the client (HMI) then the opc server only has A Channel & Device i.e the type of comms & the plc.
Most opc servers have a simulation devices i.e. kepserver has a simulation driver so R devices are used & increment & decrement at xx interval.
your HMI should only be a client so does not require the real address in this instance even if you call a variable D100 this in the opc server could be R100 (simulation I/O) or use any plc that the server can communicate with.
I assume you will be using the opc supplied dll's for the hmi client interface for example kepserver comes with a dll for use in VB,C etc.
Even if you intend to use the HMI as the route to configuring the I/O you could write it with the simulation I/O devices then change these to Mitsi when required, I know this will not help you with the real plc comms but that should be taken care of by the opc server (or are you going to write your own).
I wrote an application that fetched recipe data from an SQL database that then wrote the data to a Mitsi Q however I did not have a spare processor & ethernet card, I used the simulator in kepserver for the trial then when convinced it was working correctly connected to the plc & wrote the data to unsed addresses in the D area without any problems.