I believe you've stated the differences between the Mozilla Public License and the GNU Lesser General Public License accurately, and either may suit your needs just fine, but you are skipping over the most important difference between the two licenses:
Who can make new versions?
Both the MPL (section 10) and the LGPL (section 14) include in their license grants the right to substitute the current version with a latter version, and there are no actual limitations as to what can go into those licenses. While it's highly unlikely that either the Mozilla Foundation or the Free Software Foundation will do something as crazy as, say, institute a clause that says "all contributions to this software become our property", it's not beyond the realm of possibility that one of the organizations will release a new license version that you don't like.
Which brings up another point about using a "Modified LGPL".
A modified license is not the same license!
While you have fairly amazing ability to specify your own licensing terms, and could in essence say "you can distribute this as per the GPL, but you need to put my name in your credits and pay me 1% of any revenue you generate", any time you do so you are creating a new license based on someone else's work. This means that you're NOT using the MPL or the LGPL, you're using a new "mucaho license".
What that means is that you probably won't get any help from your original license's author if you need to defend your interpretation of the license inside of a courtroom, and it's entirely possible that they might file suit to say that THEIR version should apply and not yours.
Of course, both of these are minor points. Even "license popularity" doesn't matter unless you expect your code to be directly incorporated into larger projects.
Personally, I think the MPL is a better choice if you like proprietary compatibility, or if the choice is between the actual MPL and a different license you have to manually edit based on the LGPL. Unless you have a reason not to use the MPL, go with something backed by a foundation instead of one that might leave you in a courtroom without any aid whatsoever.
Best Answer
The quicker you make your code publicly available, the quicker you can gain feedback and people to help you. If your intention is to make the project open source from the beginning, then I would recommend starting your project out as public by default.
Github is full of small and unfinished projects so your project should fit right in. The more details you put in the readme file the better as it will help other developers/consumers get up to speed on your project quickly.
At the very least, your private projects should be under some sort of version control. If you don't want to pay for a service, then I'd recommend using Dropbox to back up your private local repositories. This way you have file backup and version control on your project which will save you from hours of pain in the future. More recently, GitHub and its competitors have released free private repositories, so you can use your version control solution of choice privately without a paid subscription.