Well, I'm not a big fan of Comic Sans for anything, but we'll give that a rest for now. (Enough people use it that somebody must think it's attractive, no matter how much the design community and us web wonks like to laugh at it rather than with it.) And "Everyones" should be "Everyone's", with an apostrophe, everywhere but in your URL. (There are other minor grammatical problems, but that's the one that makes the site look "sketchy" rather than "homey".)
The two biggest problems I can see can both be solved at the same time. There isn't enough information on the home page to make me want to sign up, and the harsh rectangles and wide borders in the banner image look really out of place on a site that otherwise has rounded rectangles with shadows and gradients. Oh, and they look clickable but aren't, which is a problem — never play around with users' expectations, since they'll just get frustrated and leave.
The icons you've used for "Find Desired Recipes" and "Bon Appetit!" look out of place in your design, but none of the icons match, really. I'd change the wording, too: there's no reason to have the word "Desired" in "Find Recipes" (another word or phrase would be better); and "Share Your Favourite Recipes" would be better than "Share Own Recipes".
So it boils down to this: you have one image that looks like four clickable things, that doesn't match the rest of the site, that has wording problems, and that isn't internally consistent (mismatched icons). Because all of the big problems I can see (I'm not signing up to go deeper) are in one place, there's one fix for all of them. There are any number of ways to fix it, but if it were me, I'd create four "actionable items"; four things that can be clicked either to get the user more information, or to start the ball rolling.
I really don't like it when a site hides all of its data behind a registration wall (unless it's clear why the data should be private or restricted, like with self-help support groups and that sort of thing). You don't need to open the site up completely, but a handful of "featured recipes" that are publicly accessible would help a lot. You don't need to give away the secrets (they can be hidden behind a "Sign up to see more" link), but you do need to get mouths watering if you want signups (or "conversions", as we call them in the trade). It's hard to do that automatically; you'd need to curate that manually (maybe based on an internal community rating system), but since there'd be a limited number of "featured" and "favourite" recipes, they can be summarized on one page (perhaps linked to the "Find Recipes" button on the home page). If you can add photos to the featured recipes, that would be great, but a bit of good copy writing can do the job almost as well. (And I know it's hard to put together a page like that before the site goes "live". Maybe for the first little while you can add a blurb that sort of dares people to add something even better, which may also lead to conversions.)
On your privacy policy page, you mention that you encrypt passwords. I really hope that's not true (encryption implies decryption). There's a problem with trying to simplify this for the masses; it tends to lead us to use technical terms in the wrong way. I'd like to assume that you mean that you're storing a salted (and, perhaps, peppered*) secure hash of the password (preferably with a high work factor, but that may be asking too much), and that while you can tell whether or not I've used the right password, the password itself is unrecoverable except by brute force. I'd like to, but I can't because you've used the word "encrypted", and that makes me nervous. If you mean that the passwords are stored in an unrecoverable format, it's better to say that.
_____________________________________
* In crypto terms, a "salt" is a per-user value, preferably a cryptographically random nonce, but the important part is that it's a different value for each user. Its job is to prevent "rainbow table" attacks, making the brute-force cracking of passwords a one-user-at-a-time deal. The salt can be stored in the database along with the hash, since it doesn't need to be any more secret than the hash itself. "Pepper" is a server secret that can be the same for all users (or, say, for all users whose username starts with the letter "a"); it's usually stored (often, but not always, encrypted) in a file that is not accessible to "world" (above the public_html or www folder) rather than in the database. It's job is essentially to change the hash algorithm (to put it simply) so that knowing the salt, the hash value, and the hash algorithm is still not enough — the bad guys have to have access to the database and the code and the pepper in order to figure out what the password was. It may not mean much to your site, but it's extra protection for users who use the same username and password everywhere.