The biggest disappointment about NVelocity is that the project is pretty much dead. Well, guess what:

Due to the lack of releases, support and bug fixes on the original port, the Castle Team decided to fork the project, bringing it to our code repository, fixing the bugs and improving it with more features.
Castle Project, NVelocity page.

And it's not only cleanup and bug fixes. How about this for an improvement?

Inspired on FogCreek's CityDesk language, the following type of foreach is supported.

#foreach($i in $items)
#each (this is optional since its the default section)
       text which appears for each item
#before
       text which appears before each item
#after
       text which appears after each item
#between
       text which appears between each two items
#odd
       text which appears for every other item, including the first
#even
       text which appears for every other item, starting with the second
#nodata
       Content rendered if $items evaluated to null or empty
#beforeall
       text which appears before the loop, only if there are items
       matching condition
#afterall
       text which appears after the loop, only of there are items
       matching condition
#end

Very cool.

I know, "Lame Perl, check out asp:Repeater/asp:DataGrid/.., dude" you'll say. Yes, sometimes. But I don't know why people are often blind to all of the related casting and DataBinder.Eval issues. It is seriously ugly.

TODO:
  * upgrade NVelocity.
  * add NVelocity rendering type.

Hopefully.

I have added the velocity master variables replacer to the extended mail action, and put them together into one project and package.
Thanks to Jakob, adding master variables replacer is as easy as it gets now, just put your class into
<setting name="MasterVariablesReplacer" value="Sitecore.Data.MasterVariablesReplacer,Sitecore.Kernel.dll" />
in web.config and derive from default Sitecore.Data.MasterVariablesReplacer. No need to hook in the pipelines!

VelocityMasterReplacer works much like the Extended mail action. Instead of having only a few predefined macro expansions like $name and $parentName, you can now use pretty much anything accessible via the Sitecore API: $user.Name, $item.Children.Count, $item.Paths.Path, $item.Fields["Text"] and even the flow control:
#foreach($child in $item.Children)
   Child - $child.Name
#end
(Make sure that you know this before trying that trick with children)

It is also backwards compatible - after the velocity replacer does its job, it calls the base method to finish the rest.
Anyway, here's the source files - SitecoreVelocity_1.1.0.0.zip (411.82 KB). (You will need Sitecore 5.1.0.4 aka 5.1 beta1 for that)

If you just need a package - its in the /data/packages folder of the archive.

Update: sorry, link fixed.

Extended mail action 1.0.0.1, built against Sitecore 5.0.7.3 and NVelocity 0.4.2.8582_Sitecore.

[Sitecore package]
Package now doesn't include NVelocity binaries - they need to be installed separately.

[Source]
Extract in the root of the Sitecore solution.

NVelocity 0.4.2.8582_Sitecore
[Source]

The only difference code wise is the 'if' clause in the constuctor of RecourceLocator class. It makes the recource locator skip the dynamic modules - they don't support GetManifestResourceNames() method

if (a is AssemblyBuilder == false)
{
    String prefix = a.FullName.Substring(0,a.FullName.IndexOf(",")).ToLower();
    String[] names = a.GetManifestResourceNames();
    foreach(String s in names) {
        if (s.ToLower().Equals(fn) || s.ToLower().Equals(prefix + "." + fn)) {
           this.filename = s;
           assembly = a;
           isResource = true;
        }
    }
}

Apart from that, I've excluded the supplementary projects like nAnt tasks from the solution. I wonder if I should merge commons into the nvelocity assembly..

I've put up a custom build of NVelocity tailored to run inside Sitecore as a separate download here:

This is a custom build of NVelocity project, tailored to run inside Sitecore CMS.
Original NVelocity had a couple of issues:

• It referenced signed log4net assembly that conflicted with the one in Sitecore distribution
• It was failing while trying to get its default properties due to a bug in RecourceLocator: dynamic modules where not supported

I needed a quick fix (it seems that nvelocity projects is not very active at the moment) so I went with the custom build.