There are many ways to calculate entropy in this situation and not all of them are in your favor. Depending upon your commitment to true entropic randomness and your level of paranoia, I think word concatenation is the least of your problems. For purposes of analysis, I'm going to assume the password example you gave above is standard for all types of passwords you create (8 complex password characters + N words containing 18 total characters -- or 26 total characters).
Assume every character in your resulting password contributes entropy to the result. Furthermore, every character may be within the range [33..126] or 94 possibilities. In this analysis, total range of passwords is 94^26 or 2*10^51. That sounds really big, and it is. However, I'm not sure that's your password range. We could stop here if we believed that an attacker could only guess from the complete range. You already know dictionary attacks are possible. Let's look at the next method.
Really, only the first 8 characters are in the complete range, the remainder (if I can guess your word component) is only lowercase, so 26 characters. This gives us a lower upper limit on your range of passwords: 94^8 * 26^18 = 1.8*10^41. That's still pretty big, but we're not done, yet.
Let's look more closely at your password structure. The first section is the only one that can have the full 94 characters, so for that we have 94^8 or about 10^16. For the second section, should we count the letters as part of the range of your passwords? I suggest they don't count, and instead we should use the total word range from which you choose and the number of words. Why? Think of the words as unique symbols rather than the characters. Your second section will never have the sequence "xxyqrzt" because there's no word that looks like that. Really, your second section follows a specific structure and that structure is determined by your dictionary. I'm going to assume 100,000 words in the dictionary, although you might only have 10,000 and that they are all lowercase. Now, the second section range is (10^5)^3 - I'm assuming three words to get to 18 characters. Our new upper bound for the password range has dropped to 10^31. Still, pretty big. We're done, yet.
OK, so this one requires us to go a bit deeper on entropy calculations across the range of passwords and then do the proper entropy calculation for your situation.
First off, password range and entropy are not the same thing, although they are related. To get the entropy of a password (or any information), we need to take the log of it's possible range. We should use base 2 for our log because it's easier and computers use it, too. In this case, we have the following entropy calculations for each of the above methods of analysis.
- Log_2(2.0*10^51) = 2^170 or 170 bits
- Log_2(1.8*10^41) = 2^137 or 137 bits
- Log_2(1.0*10^31) = 2^103 or 103 bits
It's easier to think of entropy in terms of bits.
Here's the thing. You've now published your password generation algorithm. Also, security through obscurity is not really security, so theoretically or practically, someone could discover your algorithm. In that case, the only real security for your system, the only real entropy introduced is the seed for your random number generator. If you're not using a secure RNG or a securely seeded PRNG, you've already skewed your password distribution.
What this means is that to get the full effect of your password entropy, you need to introduce at least 103 bits of true random seeding to your random number generator to select from the complete range of passwords available from Method 3.
I suspect you aren't doing this (or, at least haven't, up until you read this). So, if the RNG you use seeds itself with current time or process ID or MAC address or IP address, you might have a lot less entropy than you realize. The entire MAC address, IP address and time don't count because most of the bits therein aren't really random, they can in fact be known. Think about it. The difference between now and a few seconds from now is only a few bits of data. If I can guess when you generated the password, it might be NO bits of data. You might only have a handful of bits, perhaps no more than one dozen.
That would be a range of passwords of about 2^12 or 4000. More passwords than you'll ever need, however, you'd never know the range was so small because the passwords look so big. You can't generate more entropy from less entropy in this situation. If you don't believe me, test it yourself by running numbers from the range [1...4000] through SHA1. The results look really random. However, that's it for your hashes - 4000 only. None of the other potential SHA1 hashes are available to you because you're limited to inputs between 1 and 4000 inclusive. In this case, the entropy of the range is still 12 bits even though it looks really large. Looks can be deceiving, especially to humans.
So, forget all of your fancy analysis and multi-word fears. Instead, figure out how to get true randomness into your RNG seed. Go look up the body of research on proper RNG seeding. It's fascinating and it's really, really hard to do!