This shouldn't be a problem. I would assume the following.  But appreciate others to comment:

1. for transactions, it is unlikely you will be sending transactions simultaneously from both machines so ok.
2. for received transactions this is a read of the local chain as pulled down and resolved so shouldn't be an issue.

3. staking: If the same wallet stakes twice, it is attempting to find a block and then submit that "block solution" for the minting reward. It would make sense that the consensys algo would accept the initial solution submitted from a verified minting wallet and reject the subsequent submission.  This would be important to prevent a sybil type of attack.

4. The one issue I don't know about is the impact on imputed calculated stake time.  My assumption is that regardless of the machine submitting blocks, the stake time is calculated at the wallet level by lock-up. Having multiple wallets open begs the questions of control of staking. My assumption is that stake time/amount is relinquished reset the moment a wallet stops staking, if the follow block has a staking wallet the staking wallet would reset the "stake" toggle set.  Given the treatment of staking time it seems the best thing to do would be have both wallets stake continuously. 

Please note these are assumptions. Steve Woods would have a better answer on the impacts of a stake state that toggled back and forth due to conflicting wallets.  My guess is that the impacts to the minting reward are greater than 50% (1 machine on / 1 machine off) as the time calculation in POST has a non-linear function.