You have some assumptions here that you can work around.
The problem is, I can't use DML because it's firing from a Trigger, I can't return this field since it's a @future method and must be void and I also can't access to Trigger.new or Trigger.newMap (they are null on the future method)
The future method can in fact perform DML. The future method is running in a separate transaction; it has no access to the trigger context variables, but if you provide the Id as a parameter, it can perform DML on the original Account.
I still don't get why I can't fire an update DML statement if I'm already checking for recursiveness on my Trigger Helper.
I think your concern is that your future method will re-invoke the trigger when it performs DML. You can work around this with a simple guard structure: place a static Boolean variable shouldSuppressCallout in your trigger handler class, and code your handler not to make the future call if it's set to true.
Then, in your future method, set it to true before you perform update DML, and reset it to false afterwards.
You don't specify how exactly your recursion guard is implemented, but be aware that recursion guards based on static Booleans with a method like runOnce() are bad patterns that cause a lot of subtle problems in trigger operation. However, in the future method, all of your statics have reset because you're in a separate transaction, so it may not behave the way you're expecting it to.
