You have several options for codes like this. I assume your idea is to use the code as the primary user login, and there would be no separate password. You have several parts to the question, I will start with "is it secure?"
Short answer, probably not enough. And it is not just because of the context of invite only and no motive. There is always a motive, even if it is just "for the lulz". Just because the site is not indexed and is invite only, does not mean that some blackhat wont find it and want to play. They may not know that you have no potentially valuable information beyond the login. How much of a problem will it be if someone gets a copy of your database? How much of a problem if someones code gets stolen?
5 characters may be enough for an invite code, but as a login it is unreasonably short, even if there are a very low number of users. With the size of your code, you have between 30 and 60 million combinations depending on the generation algorithm and if you are limiting characters to avoid confusion "O vs 0". The code can always be broken into sections to make it easier to type, say A1C-B2X-YP3. 9 characters will be at least a trillion combinations.
In terms of generating the codes, one is shorter but random looking, the other is longer and natural looking. Choosing a natural language code means the user has to type more information, and also may limit the amount of combinations if they are ordered to appear natural like a sentence. How do you deal with a typos? What if a typo generates a valid login? Calling the natural language option a "passphrase" may improve things for the user, as the perception of what it is may influence the ability to recall it, and to not be intimidated by it. The other problem with a natural language code is that a user may not like some of the words, or their combination, they may find it offensive, distasteful, or have some bad memory. Some people really don't like the word "moist" for example.
As a user I would prefer a more "codey" looking code. There could be a client side check digit verification prior to the code being used to login. Limiting the amount of login attempts works a lot better if someone cannot enter an obviously invalid code. I use an algorithm to generate codes just like that using a pseudorandom permutation called Molybdenum, basically a custom block cipher resembling HIGHT. Internally it is 5 8-bit values, externally it is 8 5-bit values, encoded in 32 character alphanumeric, with "OIZS" omitted as to not confuse with "0125". Add a single check digit at the end, and it is 9 digits, which looks nice broken into 3 groups of 3. I routinely see much longer codes in mailings. New codes are generated by encrypting an incrementing counter, so they are guaranteed not to repeat. Generating codes randomly requires a check against all in-use codes to make sure there is not a collision. Using a permutation to generate codes means access to it must be limited.
You could also force a specific type of sequence like a Canadian postal code, which is alternating letters and numbers. NLN-LNL-NL(N) such as 5A9-F4E-0L0 would limit you to 4.6 billion codes, but may be easier to remember, and easier to tell when someone is having a problem. I would assume the users would not try to remember, but rather keep it written down somewhere.
If a code is used as an invite, short codes are ok, as long as they are time limited and one time use. I am assuming users will not have passwords, and only their user ID. In that case you could consider an invite code as an addition to the user ID, only used when someone has to call in for support as an additional authenticator. In this way they would use the invite code to get their user code when they sign up, then the invite code is deactivated, but stored with the account. Only the invite code would ever be mailed.
If you are not the victim of a targeted attack against your system, and you follow best practices for securing the site and database, you will probably be ok. There are many ways to store and process the login data, which is probably outside the scope of your question, that can effect the security of the system. Auditing the generation and lookup of codes by support personnel is a good idea. I have made quite a few assumptions here because of the limited information regarding the user base and site, hopefully this response is still relevant.