Interesting teaser post. I am working on a similar project currently to rewrite our Data Warehouse and Benjamin made a good point to show that DV is not a good platform for reporting - this needs to be addressed separately.
Technically a DV is pretty much box standard. Each hub and link have their own unique surrogate ID on which you hang and track the business key. The concept is what makes a DV interesting. Instead of combining keys and data into one table you put keys into one table (hub or links) and data into others (satellites). So data is separated from keys. This basic core concept is what alienates lots of people.
The other core concept of DV is "All the data all the time". So no matter whether the data is good or bad or ugly you just load it into the DV and worry about the quality later. This gives the DV a power to be a repository of all the business data. Some other system creates data for invoices that are not in the original source system? Just load it into a new satellite. How to get it into reports? That is a different kettle of fish.
Data Vault is not so much a technical scripting. It is more about the design concept that a new person needs to understand. One very nice description can be found on Hans Hultgren's site (http://hanshultgren.files.wordpress.com/2013/09/data-vault-modeling-guide-2013-v2.pdf). To make an analogy running some scripts to implement a DV is like taking a car out of for a road trip without filling up the tank - you will get somewhere but your mileage will definitely vary and arrival where you want to be is for sure very questionable.