I think this boils down to switches and event page conditions.
The first event you might start with is simply alternating between Player and Enemy Phases, which is just toggling switches on and off.
Player Phase On, Show Message "Player Phase"
Show Choices *provisional*
Player Phase OFF
Enemy Phase On, Show Message "Enemy Phase"
Common Event *provisional*
Enemy Phase OFF
Repeat
There'll be more to this, but just start by blocking in the logical flow.
For the Enemy/Player units, they're going to have at least 2 pages. For visual flare, during their active phase, you can have their sprites marching in place, while the other team stands still.
Page 1 will just be their sprite standing still
Page 2 will have the respective Phase Switch as a condition, and the event graphic set as "stepping"
You might have additional pages if this unit is dead or petrified or something.
Now the "player character" in the traditional sense won't actually be a character. We'll make it the cursor that'll jump around from unit to unit.
It'll follow some kind of manifest, a list. A turn order maybe? You might have your own system mechanic in mind, but during the Enemy phase I imagine it'll just move down a list: Event 1, Event 2, Event 3....
During the Player phase I imagine the player will select the events in any order. But once a unit performs an action, they would be removed from the the list. So once the list is empty, the phase automatically turns over.
Regarding the movement of the cursor, I highly recommend using a script call. Otherwise you'll have to go through this process of event commands: getting an event's map location, storing it to variables, moving the "player cursor" to the location based on those variables.
Or, you can save yourself the headache and just use this 1 line snippet.
JavaScript:
$gamePlayer.locate($gameMap._events[1].x,$gameMap._events[1].y)
[1] is event Id 1. But you can replace this with a variable - whatever the acting event should be.
Going back to the provisional show choices/common event; this is where units would move, target, attack ect... This is hard to talk about because there is a lot you can do in terms of system mechanics. Like movement costs or resources like "Action points" allocated to individual units or shared with the whole team. Those are design decisions you have to make yourself.
But in terms of the construction of those systems, each unit in-turn will probably use some common event process. For example, a common event that highlights an area of effect.
I think this is the main thing people get hung up on because the only kind of tile manipulation that is available through event commands is [Change Tileset]. It's fairly simple to change a specific tile from grass into water with a script call. The Map data is just an array of tile ids. All you're doing is changing those numbers. Like, $dataMap.data[0] = 2
Highlighting a grid would take a small process. More than a few lines of code. But not enough to bother creating a plugin, in my personal opinion.
My thought is to reserve the upper tile layer to be used for selection and what not.
But if you don't want to use scripts, you could probably get pretty far just using an event graphic to indicate some limited selection range.