How to justify software testing to management

First, let me say I completely sympathize with your position. It can be frustrating when you have a lack of understanding or a communication breakdown between different parts of the business. Having said that, I don't think you should try to keep them out. Instead you should show them the numbers about why this is a good idea. What facts do you have that justify unit testing is worth the effort you put into it? If you don't have any, then you should start to gather those figures, or show some research to back up your claims.

I have had to deal with similar scenarios myself and I answered this question on a similar topic. I also blogged about how I dealt with it here:

http://practicalagility.com/show-them-the-numbers-its-results-that-matter/

In case you don't feel like link chasing, I'll repeat my summary from the related question:

To summarize, I compared our estimated hours against actual hours for the project and then compared our defect rate against other teams' defect rate. In our case these numbers compared favourably and there were no more concerns.

My conclusion based on this experience is:

...the best way to convince anyone that your approach to doing something is practical and pragmatic, is to do it and measure it against other approaches. People don’t care about dogma, or why you think something should be the best way. Only by showing people the numbers and measuring the effectiveness of your approach can you truly show that your practices are effective.

If your management team don't agree to investing what they see as an additional 150 hours on unit testing, perhaps you can convince them to invest in one small area of the product (or even agree to suck the hours up yourselves to provide some data). Do unit testing in that one area of the product then gather data about the defect rates in that area of the product and the cost to find and fix those defects compared to the defect rates in other areas of the product. Hopefully you'll gather some data to back up your case and this will be a non-issue for your next project.

Let me play devil's advocate for a moment:

Specification of the tasks at hand is sparse... The Lead Dev is very fond of what he calls 'prototyping'

The lead dev is fond of prototyping because specifications are sparse. This is probably a good thing; this is how iterative shops work.

The modellers are expected to tell us everything about the desired methodology in precise detail

This won't work in an iterative shop. The very nature of iterative development is that requirements are often incomplete. The iterations are what is needed to flesh out the requirements.

I've tried to push TDD in the team before, but found it difficult as it's new to me

This won't work either; you need to understand the technology before you can evangelize it. Further, in an iterative shop with scant requirements, TDD may be too much overhead. It's better to encourage adequate unit testing coverage.

We now have a continuous integration server, but it's mostly only being used to run multiple-hour regression tests.

That may be appropriate in a small, iterative shop.

Every time I raise the issue of quality with the lead dev, I get an answer to the effect of 'Testing feature A is straightforward, feature B is much more important to the user but too difficult to test, therefore we shouldn't test feature A'

It sounds like your shop has some fairly tight time constraints; like it or not, you are bound by those constraints.

It also sounds like you came from a part of the software industry that values doing things "the right way" over getting things to the market first. There's nothing wrong with that (it's admirable, in fact), except that the first to market with a buggy piece of software is often the winner. It's not fair, but that's how it is.