If the KGC gets compromised it will break security, so why should a KGC generate private keys.
Certificateless crypto tries to overcome the problem which exists in identity based crypto, i.e., that the KCG generates all the private keys of the users (that is necessary in IBE, see below) and thus knows all the private keys of users (which in turn enables the KCG to decrypt all the ciphertexts intended to it's users). Certificateless crypto is similar to IBE (thus requires a KCG), but does not reveal the entire private key to the KCG.
However, if the KCG in certificateless crypto gets compromised, then you have a problem which also exists with certification authorities (CAs) in public key crypto. In particular, someone who gets the private key of the KCG in certificateless crypto or of the CA in context of public key crypto can incorporate all users he would like to. Essentially, due to fact that he can issue "fake" keys on behalf of users and pretending that they are authentic keys. However, in IBE a compromise is much more devastating than in certificateless crypto or public key crypto, since in the latter two cases the adversary may only issue new "fake" keys but is not able to regenerate all the previous keys as it is the case with IBE (which allows him to decrypt all the previous ciphertexts intended to registered users).
Will it be possible that user will generate pair of public and private keys and for authenticity of public key only, we will use some trusted center?
That is the case in public key crypto (but as said above, that will not help against a compromised CA which certifies the keys) and in part the case with certificateless crypto.
If we do not assume a compromise of the CA/KCG but that the KCG works as it is supposed to work, then one can subsume the three different concepts as follows. I'll try to give you the big picture and hope it helps you to understand the idea of certificateless public key cryptography.
We have three basic approaches in the field of public key cryptography:
In traditional public key cryptography, a user $A$ generates a private/public key pair $(sk_A,pk_A)$ locally and since this key pair has absolutely no indication to which indentity (user $A$) it belongs, it is necessary to certify the public key, i.e., bind the public key $pk_A$ to the user $A$'s identity. This is commonly done by letting some trusted authority, a certification authority (CA), sign $pk_A$ with additional identifying information of user $A$ after user $A$ proves by some means that he really is user $A$ (the result is what is called a certificate). To encrypt some message for users you have to obtain an authentic public key of the CA and for every user.
Identity-based cryptography aims at letting the users public key be its identity (e.g., the email address) and so to remove the requirement for certificates. In ID based cryptography a user $A$ uses his identity (e.g., his email address) as public key. Now, however, since this identity could be used by anybody to compute the respective private key, it is clear, that there needs to be some other entity involved in generating the respective private key (To see the requirement for such an entity, think of the fact that I could use your email to compute a private key for your identity otherwise). We require a trusted authority (the KCG) owning some secret master key to compute the private key $sk_A$ that corresponds to the public identity string $ID_A$ and this trusted authority has to check whether $ID_A$ (e.g., the email address) indeed corresponds to $A$ and then issues the private key $sk_A$ corresponding to the identity $ID_A$. The advantage is, that you only need the parameters (corresponding to the master secret) of the KCG in an authentic fashion but no longer any authentic key of the users. Now, however, the KCG knows your private key and may use this private key to decrypt your messages, so it needs to be fully trusted. That's an inherent problem of identity based cryptography, although one may implement multiple KCGs (each having a share of the master secret) who compute the private keys for identities in a distributed fashion, so that neither gets to know the entire private key of a user. But it is questionable if this is really practical.
- Certificateless public key cryptography is inbetween these two approaches. It aims to get rid of the problem that the KCG gets to know the entire private keys of all users. Having said that, in this approach the KCG only computes a partial private key of user $A$ based on the identity $ID_A$ (clearly, also here user $A$ has to prove by some means that $ID_A$ is associated to him) and the user then combines this partial private key with some secret information (only known to him). Consequently, the KCG no longer gets to know the entire private keys of the users. Then a user, however, needs to take the parameters of the KCG and needs to combine the user chosen secret with this parameter to obtain an additional user public key. So, to encrypt a message for a user the identity string plus this public key is required. The advantage here, however, is that this public key does no longer need to be certified, since it contains the identity $ID_A$ of user $A$ and if the KCG is trusted (and the parameters of the KCG are authentic) one can assume that the user associated to $ID_A$ really corresponds to $A$ and holds the corresponding private key.