If the sole purpose of defining my-trash-dir is to use its value to set the user option trash-directory, then you should just write
(setq trash-directory (expand-file-name ".trash" user-emacs-directory))
or (if you don't mind wasting a millisecond or two at startup) even
(setq trash-directory (locate-user-emacs-file ".trash"))
This is because trash-directory is automatically created for you when the command move-file-to-trash is invoked. Deferring the creation of trash-directory until it is actually needed will even improve your startup time.
If, however, you want to use my-trash-dir as a variable for other purposes, there is nothing wrong with using a plain setq to define it:
(setq my-trash-dir (locate-user-emacs-file ".trash"))
(setq trash-directory my-trash-dir)
(unless (file-exists-p my-trash-dir)
(make-directory my-trash-dir))
There is almost never a need for users to use defconst, especially given the Emacs philosophy centred around customisability. But there are several advantages to using a defvar:
(defvar my-trash-dir (locate-user-emacs-file ".trash")
"Personal Emacs trash directory.")
(setq trash-directory my-trash-dir)
(unless (file-exists-p my-trash-dir)
(make-directory my-trash-dir))
You can associate a docstring with it which will be presented by C-hvmy-trash-dirRET and reduces the need for comments in your code.
Emacs notes the file in which the variable was defined. You can then jump to this location via M-xfind-variableRET or the hyperlinked button in the *Help* buffer.
The byte-compiler is made aware of the variable so that it does not complain, should you want to byte-compile your code. The variable also satisfies special-variable-p, should you ever care about this.
You will be one step closer to achieving Emacs zen[1]. In other words, it is more idiomatic and elegant to define variables prior to their use.
[1]: This claim is provided "as-is", without warranty of any kind.