Not only you can encapsulate the mechanisms of object creation into Factory, but you can use Decorator pattern to define flexible enemy structure. Because you use a xml to define object structure, it would be very flexible to define a bunch of decorators and to play with them in the xml.
  See this class diagram for enemy composition

I can't define behaviour of decorators for now, because I don't know the responsibilities of your enemies, but as far as I can see decorators would escalate render call to wrapped object, but add some behavior on update method. In addition, you can consider creating other principal classes besides NormalEnemy.

You can also examine using Composite pattern or similar way in dealing with this complexity, which if described in this article: Refactoring Game Entities with Components

Not only you can encapsulate the mechanisms of object creation into Factory, but you can use Decorator pattern to define flexible enemy structure. Because you use a xml to define object structure, it would be very flexible to define a bunch of decorators and to play with them in the xml. Possible class diagram for enemy composition:

I can't define behaviour of decorators for now, because I don't know the responsibilities of your enemies, but as far as I can see decorators would escalate render call to wrapped object, but add some behavior on update method. In addition, you can consider creating other principal classes besides NormalEnemy.

You can also examine using Composite pattern or similar way in dealing with this complexity, which if described in this article: Refactoring Game Entities with Components