Disable warning about emacs.d in load path

Don't disable the warning. It's there for a good reason: ~/.emacs.d shouldn't be in your load-path.

This is because Emacs writes files to this directory, and therefore it's possible (there are existing cases) for those files to conflict with the names of elisp libraries. If you have this directory in your load path, and you have such a name clash, then Emacs will attempt to load the wrong file if that library is required.

Just change your configuration. It's trivial to move the elisp libraries you've placed in that directory into a sub-directory, and then update the code which was adding ~/.emacs.d to your load-path, so that it adds the new sub-directory instead:

(add-to-list 'load-path (expand-file-name "~/.emacs.d/lisp"))

Precaution

Your .emacs.d can safely be in your load-path only at the end. This will ensure that if a file in your .emacs.d conflicts with a library, the library will take precedence. With add-to-list, you can do this by setting the third parameter (APPEND) to t:

(add-to-list 'load-path (expand-file-name "~/.emacs.d") t)

Disabling the warning

Adding 'initialization to warning-suppress-types or warning-suppress-log-types will suppress the warning, but you also won't see errors or warnings if something goes wrong in your init file.

The solution I use in my .emacs.d is an advice that selectively ignores this warning based on the warning message:

(defadvice display-warning
    (around no-warn-.emacs.d-in-load-path (type message &rest unused) activate)
  "Ignore the warning about the `.emacs.d' directory being in `load-path'."
  (unless (and (eq type 'initialization)
               (string-prefix-p "Your `load-path' seems to contain\nyour `.emacs.d' directory"
                                message t))
    ad-do-it))

This will need updating if the warning message changes.

Organization tip

If you want to keep personal files directly in your .emacs.d directory, it may be a good idea to unclutter it by making a dedicated directory for the savefiles of various packages, for example:

(defvar my-savefile-dir (expand-file-name "savefiles" "~/.emacs.d")
  "The directory for automatically generated save/history/etc. files.")

and then, for each package that puts its file in .emacs.d, something like this:

(setq tramp-persistency-file-name
      (expand-file-name "tramp" my-savefile-dir))

Update to organization tip

Since writing the above, I've discovered that packages usually use locate-user-emacs-file to get the paths to files in which they store their data. This function returns an absolute path to a file in user-emacs-directory. By default, user-emacs-directory contains the path to your .emacs.d, but you can change this to a directory where you want your savefiles (you'll probably also want to preserve the old value somewhere):

(defvar main-dir user-emacs-directory
  "The root directory of my Emacs configuration.")
(setq user-emacs-directory (expand-file-name "savefiles/" main-dir))
;; The trailing slash is mandatory.

This will make most packages store their files in .emacs.d/savefiles. If you want to make an exception, so that a given package stores its files directly in .emacs.d, use something like this:

(setq package-user-dir (expand-file-name "elpa" main-dir))

You'll also have to change settings of packages that get loaded before your init file, and therefore use the original value of user-emacs-directory:

(setq auto-save-list-file-prefix
      (locate-user-emacs-file "auto-save-list/.saves-"))

In addition, some packages use hardcoded paths instead of locate-user-emacs-file, but that's easy to fix too:

(setq smex-save-file (locate-user-emacs-file "smex"))

Most packages use locate-user-emacs-file though, so in my experience this method of organizing savefiles requires less code than the one from the original "organization tip" (as of writing this, the above fragments of code are the only savefile settings in my Emacs configuration, while the original method required a line for each package).

I don't know if this method is an intended use or an abuse of the user-emacs-directory variable. I use it and it works without issues so far, but your mileage may vary.