Sounds like a pretty straightforward deployment.
It sounds like you've already created your domain. Since you're using SBS, be aware that the existing SBS machine will be forced to hold all the Active Directory flexible single-master roles. That's probably not a big deal, but the 75 user limit in SBS might be. While SBS makes for an attractive price-point to get a cheap bundle of Windows and Exchange, you might be better off just purchasing Windows and Exchange Server licenses if you're going to approach the 75 user limit. You also won't be able to use Windows SBS in each remote location, if you want this to be a single Active Directory / Exchange infrastructure. You can only have one Windows SBS Server in a given Active Directory forest, so you'll need to purchase "plain vanilla" Windows Server and Exchange Server licenses for the remote locations. (I'd purchase volume license seats of Windows Server 2008, personally, such that you are allowed "downgrade" rights to W2K3 and so that you can re-assign the software to new server computers in the future w/o "re-buying" it as you would have to with OEM-licensed software...)
This initial DC should be a DNS server, and it should use either use root hints or forwarders to your ISP's DNS servers to allow it to resolve Internet names. If you want to use it as the DHCP server for the LAN in the central site, set that up, too.
This is also a good time to plan out the IP subnets you'll be using for the remote offices, and to create the entries for sites (groups of subnets that have "good" connectivity between them-- typically a single WAN / VPN location), subnets, and site-links. If your VPN is a mesh, you can connect all the sites together with a single site-link. If your VPN is hub-and-spoke you should create a site-link to connect each spoke site to the hub site. If your VPN doesn't allow communication from one spoke to another spoke across the hub then you should turn off "Bridge all site links". I'm glossing over this w/o providing much detail, but you can find detailed documentation from Microsoft. Getting this right is essential to getting Active Directory replication running right, and Exchange 2007 mail delivery functioning properly to remote servers. (If you stick with E2K3 then there's no Active Directory site topology ramification.)
Since your domain already exists, you can start to build up the DCs for the remote sites. You can do this via VPN connections or you can prep the servers on the LAN with the initial DC. Either way, be sure that the new DCs, which start their lives as "plain vanilla" Windows Server machines, use the initial DC for DNS until they're promoted to being replica DCs for your domain. Verify that the machines becoming replica DCs have good DNS before you proceed. You should be able to lookup the AD domain name using "nslookup" and get back the exisiting DCs names / addresses. If you can't, figure out why before you proceed.
Once you've promoted a replica DC, install the DNS Server service onto it. Make sure that each DC for a remote office is also marked as a "Global Catalog" server (in the "NTDS Settings" properties under the server object in "Active Directory Sites and Services"). That will speed logons at client computers and make Exchange email delivery work w/o requiring the VPN in each remote location.
Using a single Active Directory domain will cause all your servers to share a common Active Directory database, including user accounts, groups, OUs, group policy, etc. Unless you have very large numbers of users (and, since you're planning on using SBS, you're limited to a single domain anyway) you should be just fine w/ a single AD domain for everything. (Heck, even if you did have very large numbers of users I'd still steer you toward a single domain unless you had some other mitigating factor that caused you to need multiple domains.)
I'd plan for group policy objects to handle "Folder Redirection" into shared folders on each remote office DC for user's "My Documents" and "Desktop" folders. I'd also deploy roaming user profiles. I would work toward having stateless client computers. I would organize my user objects into OUs that represent remote locations, and then by role from there, if necessary. (I do this with the assumption that you'll probably end up delegating control for some "computer person" in each remote location to perform password resets, so having the users laid-out by physical location gets you some of the way there.)
I'd put client computers into OUs representing each remote location, and apply group policies as necessary (to direct clients to the appropriate WSUS server, etc). Later on, I'd use DFS and replication (which type depending on the version of Windows Server you have) to replicate a folder hierarchy that contained any Windows Installer packages for software that you want to "push out" to client computers in the remote offices, such that each office has a replica of the installation packages folder hierarchy.
If you have the R2 verson of Windows Server everywhere you can use DFS replication (DFS-R) to replicate folder hierarchies from the spoke servers to the hub server (and the converse). In theory, you could replicate a folder hierarchy to all the spoke servers such that users could transparently move between locations and access locally-cached copies of their profile and redirected folders. In practice, that usually doesn't work because DFS-R replication doesn't end up keeping up with the traffic. For maintaining a central copy of the spoke servers at the hub for backup purposes, though, DFS-R may do what you need.
re: Exchange - I see what you're trying to do with the MX's, I think. You're interested in seeing inbound Internet email for each remote location delivered directly to that location's SMTP server, versus being delivered to the hub and then distributed across the VPN. You can do that, but because of email antivirus and anti-spam concerns you may find that it makes more sense to have email delivered to the hub and then distributed to the reomte sites.
It's unclear what you mean by running Exchange "independently". All Exchange Server computers installed in the same Active Directory forest share a common configuration, the Exchange "Organization". You would have to have multiple Active Directory forests in order to have multiple Exchange Organizations, and you really don't want that.
I would deploy a single Exchange Server computer into each remote location. Each Exchange Server computer would host mailboxes for users in that location, and would be capable of delivering email directly to the Internet and to the other Exchange Server computers in the network.
If you're thinking that you need "site-specific" SMTP addresses and MX's for Exchange to work at all, that's not the case. Exchange doesn't use MX records to deliver email between different Exchange Server computers of the same Exchange Organization.
In your network, you would deploy additional Exchange "routing groups", each one representing a remote location and containing the Exchange Server computer for that remote location. "Routing group connectors" (or other types of "connectors") are used to convey the network topology to Exchange (much like Active Directory uses the "site" and "site-link" topology to calculate replication paths). Exchange will "just know" to contact the appropriate remote server when email is sent from one remote location to another. The SMTP address and MX records aren't used in this process.
It's unclear to me why you are concerned that the VPN not "be up" 24 x 7. It's virtual, by nature, so there shouldn't be any added expense to having the VPN available all the time. I'd use good quality hardware VPN termination equipment to terminate VPN tunnels at each remote location in either a hub-and-spoke or mesh fashion, depending on how many remote locations you had. (Personally, I'd use either Cisco ASA-5505 devices or small server computers running Linux and OpenVPN, but there are any number of possible solutions out there.)
You can schedule Active Directory replication (and even Exchange mail delivery / public folder replication) to occur in off-hours if you want to keep the VPN reasonably free of traffic during regular business hours. To my mind, I'd keep the VPN up 24 x 7 and use it for constant AD and Exchange traffic, since it would appear that you're trying to keep user files stored in each office and, in general, users won't be sending traffic across the VPN.
I recommend deploying Windows Software Update Services (WSUS) while you're doing all of this, too. You can get documentation from Microsoft on the specifics, but I'd plan on a central WSUS server with replica servers running at each remote location. As I said earlier, I'd use group policy applied at either a remote-location OU or the Active Directory site to direct client computers to their closest WSUS replica.
No doubt you'll be told that you need various separate servers in each remote location for this. You can use a separate physical or virtual machine for each "role" if you'd like. I'll tell you, from my own experience, that you could get by with a single physical machine acting as a file server, DC, WSUS server, and Exchange Server in each remote location just fine, so long as the machine is "beefy" enough for the count of users in the location. It would be nice to have physically separate machines, but only if the load warrants it. (Now doubt I'll get comments from nay-sayers about how Microsoft doesn't "recommend" that you run Exchange on a DC... and while this is true, the Windows SBS product does just that, and it works fine. All I can figure is that these types of commenters have either an unlimited budget to buy Windows Server licenses or they've never actually had to deal with the realities of making a small budget go a long way.)
Be aware that your users won't have a central URL with which to access Outlook Web Access for webmail in this scenario. Exchange can provide such a central URL, but it would be based on having a "Front End" Exchange Server computer that would access the "Back End" servers in each remote location via VPN. It might just make more sense to tell users to access OWA via a remote location-specific URL and then provide the appropriate port-forwards at each remote location for OWA.
Whew. That was fun.
If you're not super familiar with the products involved you would do well to spend some time in a lab scenario mocking this up. If you're still concerned, find a consultant (with good references) who will work with you face-to-face for a few hours doing the setup for the first remote office. Take copious notes, ask a lot of questions, and gather all the details you need so that you can do the next office(s) yourself. (Believe it or not, there are consultants who are happy to "teach a man to fish". Personally, I hate repetitive work and, while I do enjoy making money, I'd rather teach a Customer how to do something themselves, if they so choose, than do the same thing over and over again.)
As I said, this is a pretty straightforward deployment. You're trying to use the products (perhaps with the exception of SBS, depending on your user count) for exactly what they were intended to be used for, and you're not going to find yourself "fighting" the products.