Sorry but I'm going to say it, your idea isn't even remotely possible. Your document was created without enough consideration for implementation, it's a story, and just like a story it's not bound by reality.
With that said, the core goals are reasonable, you just have to scrap the details.
All of this can be done. I'll note however, it's much more complicated than your standard fare RPG, so if you aren't an extremely experienced programmer and game developer I suggest you table this for a few years. In any case here's some advise on how to make it work.
The whole "particle" thing? It sounds utterly inane. Save it for the game's lore.
The best way to handle elements will probably be to tag objects and regions. They don't need to be physical, interactive, or even visible things beyond their natural representation; a chair is a chair, it's made of wood, and a fireball is made of fire. Objects have tags that define their makeup, when a spell targets or collides with them, how it behaves is determines by its tags (makeup).
The spells themselves would have to be created from components, each of which having their own behavior that contributes to the end product.
Let's look at some examples to clarify and illustrate what they may need
First up is a multi-fireball spell. This spell has three steps, first it needs to know where to make the balls, then it needs to create the balls, and lastly it needs to propel them. That would be a "multiple", "condense (heat)", and "propel" components.
If you take the multi-fireball and replace "condense (heat)" with "push (heat)", it now defines a multi-nozzled flamethrower. If you instead replace "condense" with "pillar", you now have a wall of fire pillars.
Let's look at another example... Icicle rain. It's an ice spell, it requires either ice or the freezing of water to cast it, it moves forward, after a time delay it explodes creating many small shards, and each of these shards also move. This introduces another need, some of these parts don't perform their function immediately, they may have delays or loops.
Another consideration is that some components may require different input, so your system will need to recognize a few different types of spells; self-cast/aimed/targeted, instant cast/channeled, etc.
In order for spells to be able to interact with other elements, you need to first define how they behave. Fire hitting water will lose heat and evaporate the water, lightning hitting water will be absorbed (modifying the object) and damage anything it touches, and a fireball hitting a smaller fireball might absorb its heat making it stronger.
With basic interactions defined, the spell components need to determine how to use them. While a fireball might go off in one big blast (smoke screen anyone?), a flamethrower will continue spewing fire until its source is extinguished.
All of that is just me glossing over the general idea. There's a lot more that needs to be considered, and implementing it is orders of magnitude more complex than just understanding the gist, but I don't have the time or motivation to write an essay about it :P
If this means anything more to you than a whimsical idea, I recommend you build a simplified prototype. If it was me, I'd start with a spell designer (component based spells), and if that went okay, move onto spell/object interaction (chair, meet fire).