GM: S can definitely be used to make a Pokemon fangame. I'd suggest that you keep all the global information--such as Pokemon and their data--in a ds_map structure. Probably using the Pokemon number as the key, and then a second-tier map handle as the value. This way, you can create, modify, and access the information you need at any given time in a more human-friendly way than if it were all numerical indexes. In addition, GM: S has a pair of handy functions that can encode nested maps as a JSON object string, and decode them back to maps, meaning that during testing and the final product, your saving and loading will be vastly simplified.
As for OWs and battles, here's a tip: use instance creation code to set local variables for everything that makes each OW unique. That way, you can just have instances of a single OW object which each behave uniquely in the game based on their variable values. And for battles, a similar idea helps: have just a single battle room with an initializer object instance in it. That object will control the battle as it goes, based partly on data stored in global variables (i.e. a global map of opponent's Pokemon and their stats, an array of trainer items, etc.). This way, the OW can simply set that global data when interacted with, based on its local variables, and then send the player to the battle room.
As for battle AI...that completely depends on how much work you want to put into this. AI is a broad field, and it offers lots of flexibility depending on what you want from it. The naive approach would simply be to simulate every option each turn (i.e. each move and each item usage) and then choose the option that results in the highest self-heal-to-enemy-damage ratio. That ignores things like inflicting status effects and the possibility of swapping Pokemon, and it doesn't think ahead, but it's basically okay; more advanced AI requires you to work out patterns in general player behavior and code those up yourself :)
In short: yes, this is definitely possible to do, and there are many ways to do it.
I agree with the previous posts, GM: S could work quite well for a Pokémon engine.
The syntax used for using the data structures is a bit of a pain though, and being unable to declare custom objects (objects as in OOP, I'm not talking about GM: S objects here) makes implementing the thing rather difficult. You can't just create an object called PokedexEntry, for instance, and make methods for it, like pokedexEntry.markViewed(true) or something.
This is the biggest reason that, frankly, could deter me from attempting to create a Pokémon engine in GM: S. I don't like not being able to use real, flexible OOP and relying on a bunch of scripts.
If that doesn't stop you, then... go ahead!
While I certainly understand the appeal of OOP syntax, don't forget that GM's objects have user events, which can be used like member methods. Sure, it's not exactly the same thing, but it's functionally quite similar, and I feel the shortcomings of it are far made up for by GM's abstraction of things like rendering, audio, and window management.
