Good question. My short answer is that the package name for all my compendia is simply compendium so I don't have to come up with a unique CRAN-compliant name. Here's my reasoning:
I often create compendium-style projects that don't have any functions in a R/ directory, and consist only of .Rmd files and a DESCRIPTION; e.g. https://github.com/cboettig/noise-phenomena . In such cases, the DESCRIPTION serves only as a place to keep basic metadata and manage dependencies; i.e. you (and Travis CI) can devtools::install() the compendium as a way of installing the dependencies (including use of Remotes from GitHub, as in that example), but you would never load the package with a library() call (since it doesn't provide functions anyway). As such, the package name is rather moot -- you'll see that example simply says Package: compendium, just like my template: https://github.com/cboettig/compendium/ .
Maybe this is just lazy and having a bunch of compendia all called compendium is a bad idea, but as they don't contain any functions or NAMESPACE anyway, there's no actual NAMESPACE collisions. So I try to follow this model for things that are strictly a 'compendium' (no functions in R/, not intended to pass R CMD CHECK. When I do need custom functions, I tend to put those separately in a proper package that has tests, some docs, and can pass checks (and thus has to have a decent package name). This also helps me separate things that are 'just compendia' from 'proper packages', i.e. it's okay if future work depends/imports an actual package, but I'd rather not have compendia importing functions from a previous compendium.
Not sure if that made any sense or is ill advised, but would appreciate thoughts either way!