The problem is, everything is in a DAT file. I have spent time messing with the patcher and figured out how to download directly from ArenaNet. The instructions are near the bottom. I wrote myself a script that downloads the file, reads the first 250 characters. And based on a few if statements, adds extensions and puts them in folders to the best of my knowledge of what they are.
I can give you the script, but I would prefer to give it to you over PM or privately. I don't want to just post the script here for anyone to download, since I don't want people to just hammer the server. The script downloads Uncompressed files, so traffic would be high and they might figure it out if like 20-30 people are hammering their servers trying to get uncompressed files.
So tell me your preferred method for me to send you the script.
Just letting you know, it is a very simple and messy script in python. So its not perfect on sorting them (Ive had a few MP3 files go into the TEXTs section with a .TXT extension) but I believe most if not all DDS are properly sorted.
I have also no way of telling what kind of file any fileis until downloaded. So you might have to download lots of unwanted files. I have 23 gigs of files atm. My script died, so it stopped at 23 gigs, and the texture folder is 15 gigs.
So, anything I can help or provide you with to get you the files you want? A bigger sample of DDS files? the Game EXE/Patcher is in the thread I linked above.
But this was on the Xentax Wiki for GW1's DAT in the TALK section:
So here is the image I extracted from one of the ATEX sections in my archive. It was the second ATEX section, which I used because the first had 'DXTA', which isn't an actual compression format. This one was 'DXT5', though it isn't exactly that anyway. For reference, the data is here: http://rep.undev.org/gw/07537E00.dat
The image data starts at 0x1c. The only obvious element of the header is the width and height, which are the first two shorts after 'ATEXDXT5'. The image data works as normal DXT5  with a few differences. First, only the alpha part is there. Normally, it is organized into 4x4 pixel blocks (texels) with eight bytes of alpha information and eight bytes of color information. Here, the color information is missing, so texels are only eight bytes. To view the image, I added a DDS header and put in eight byte blocks of zeros every eight bytes throughout the image data.
With that done, the image still wasn't right, but it was obvious that it was missing several texels, which shift all the following texels left. The missing texels were the ones in the four corners of the image (all zero data, since they are completely black). I am pretty sure that for extra compression, they leave out these texels and give their offsets elsewhere (only about two bytes to store the offset, rather than keeping the eight bytes of empty image data). If I counted correctly, the offsets (in texels, not bytes) of zero texels for that image are 0, 7, 56, 63 or 0, 6, 54, 60, depending on whether you add one for each previous texel. I haven't examined the data very carefully for these values yet.
I don't know how to get the right lower mipmap levels yet. What is interesting is that assuming normal DXT5 data (color included and no missing texels), the sizes work out perfectly for a 32x32 image with 6 mipmap levels if you start the image data at 0x14. Maybe GW needs to trick DirectX into thinking it's dealing with real DXT5 data at some point.
I hope this helps.