Ok...I'll answer this with code, just for the sake of it. Consider this a kind of code-golf-with-triggers-in-apex answer.
But why would you do it when you can use a formula field?
In the docs it clearly states that in the after state, the sObject instances of Trigger.new are read-only. So what you are attempting (calling update on Trigger.new in an after trigger) will fail. The main reason for this is the fundamental problem of calling update on a record that has already been saved/inserted (but not committed) to the DB. Also there is the problem that calling update on a trigger with an update trigger on it creates a race condition where trigger triggers trigger, triggers trigger, ad nauseum, ad governor-limit-exceptium.
But again, why on earth would you bother when a formula field would work, take less time to implement, and not require test code.
That's not to say your trigger can't update the records in the after state...you just need a new instance to write to the DB. Then you need a static variable to stop the race condition.
There are many posts and many blogs on how to avoid trigger race conditions.
Using a static variable. Using a more advanced structure. So look closely at that. I'm not going to waste space here to repeat those examples.
As far as getting the accounts to save, you need to create a list of new Account instances to work with...not just pass the reference to the ones in Trigger.new.
List<Account> listOfAccountsToUpdate = new List<Account>();
for (Account a : Trigger.new){
//creating the new account instance is key. this decouples the record
//in the DB from the R.O. instance sitting in trigger.new
Account newAccountInstance = new Account(Id=a.Id);
newAccountInstance.ID_of_Record__c = a.Id;
listOfAccountsToUpdate.add(newAccountInstance);
}
update listOfAccountsToUpdate;
Of course, you're going to do this as a formula field in production anyway, so this really is pointless, right?
One final thing...
You can actually skip the possibility of recursion by not making this an update trigger. If all you are doing is copying from Id to your custom field, update is superfluous. Id is not updateable. Yep, the system will never update that Id value, so take out the after update and you remove a lot of potential pain for yourself, future developers, and your users.
But I don't want you to vote for my answer. So please, please, pretty please, don't check it as correct. Check formula field answer as the correct one.