Your tool is exactly what i think makes the most sense so far in having go work with DB. It's type safe (assuming the tool is correct), and doesn't add complexity in the code or complex and magic libraries.
It also makes the database schema the source of truth for a system, which makes the most sense to anyone that has really worked on complex systems (most of them having the DB be accessed by multiple subsystems, written in different languages).
If you're actively using xo, I'd love to know more about how you're using it. I'm in the middle of writing up some real world examples of how to use it, and would love to be able to point to work done by others.
i stopped using go because it didn't have a good enough db access library (i like using ORMs for prototyping, and then see what really needs to be recoded with direct sql later).
Not sure how you did this, but this kind of data layer generation tools were pretty common in the early C# days, you should have a look and see how they worked. The main idea is to keep a "_generated" folder independant from the rest of your code, and let people enrich your models with methods in separate files (so that you can regenerate without breaking anything). But go makes all that pretty easy, so i assume it's already the case.
Another feature is to be able to configure how many foreign relationships are queries at the same time when you request one top object, to be able to optimize db access on the most common paths.
It also makes the database schema the source of truth for a system, which makes the most sense to anyone that has really worked on complex systems (most of them having the DB be accessed by multiple subsystems, written in different languages).